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Abstract 

As  software  system  requirements  become  more  complex,  software  engineers  must 
carefully  design  the  systems  to  ensure  the  systems  adequately  meet  all  the  requirements, 
both  functional  and  non-functional.  Because  real-time  systems  have  timing  constraints, 
in  addition  to  the  more  traditional  behavioral  constraints,  a  comprehensive  software  de¬ 
sign  analysis  model  is  required  which  incorporates  performance,  timing,  and  behavioral 
constraints.  Although  the  Ada  language  tasking  constructs  are  compiler  independent,  Ada 
tasking  is  dependent  on  its  runtime  environment;  therefore,  a  formal  model  of  Ada  tasking 
and  its  associated  runtime  environment  is  important  in  order  for  system  designers  to  make 
realistic  decisions  when  mo<^eli_ng^Mission  Critical  Computer  Resources  (MC’CR)  systems. 
The  main  focus  of  this' I'WWnill  ufTort-is  to  determine  the  feasibility  of  developing  a  pa¬ 
rameterized,  formal  model  of  Ada  tasking  and  the  associated  runtime  environment..  'Phis 
research  shows  that  such  a  parameterized  model  can  be  developed  using  a  mathematical 
model  which  incorporates  real-time  scheduling  and  queueing  theory.  This  model  can  be 
used  in  the  future  to  develop  a  design  analysis  environment  for  real-time  embedded  soft¬ 
ware  systems  that  require  Ada  as  the  target  language.  Thus,  given  a  specification  for  such 
a  system,  the  design  analysis  environment  can  be  used  to  obtain  the  information  needed 
to  support  Ada  software  design  decisions. 
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A  FORMAL  PERFORMANCE  MODEL 
OF  Ada  TASKING 


I.  Introduction 

1.1  Background 

The  Department  of  Defense  (DoD)  sponsored  the  development  of  Ada  in  order  to 
combat  increasing  software  complexity,  especially  in  embedded,  real-time  computer  sys¬ 
tems.  Embedded  applications  tend  to  be  large,  long-lived,  subject  to  continuous  change, 
subject  to  hardware  constraints,  and  are  required  to  be  highly  reliable  and  fault  tolerant. 
(3:15).  The  DoD  has  recently  mandated  Ada  as  the  “single,  common,  computer  pro¬ 
gramming  language  for  Defense  computer  resources  used  in  intelligence  systems,  for  the 
command  and  control  of  military  forces,  or  as  an  integral  part  of  a  weapon  system'’  (7:2). 
These  systems  are  typically  large,  embedded  computer  systems  which  have  real-time  pro¬ 
cessing  constraints. 

Real-time  systems  are  divided  into  two  groups:  hard  real-time  systems  and  soft 
real-time  systems.  “In  soft  real-time  systems,  tasks  are  performed  by  the  system  as  fast 
as  possible,  but  they  are  not  constrained  to  finish  by  specific  times.  On  the  other  hand,  in 
hard  real-time  systems,  tasks  have  to  be  performed  not  only  correctly,  but  also  in  a  timely 
fashion.  Otherwise,  there  might  be  severe  consequences”  (2-1:151). 

“Hard  real-time  systems  are  defined  as  those  systems  in  which  correctness  of  the  sys¬ 
tem  depends  not  only  on  the  logical  result  of  computation,  but  also  on  the  time  at  which 
the  results  are  produced”  (24:1).  Because  real-time  systems  have  timing  constraints,  in 
addition  to  the  more  traditional  behavioral  constraints,  a  comprehensive  software  design 
analysis  model  is  required  which  incorporates  performance,  timing,  and  behavioral  con¬ 
straints. 

“Embedded  computer  systems  are  usually  defined  to  be  those  computer  systems  that 
constitute  a  part  of  a  larger  system  whose  primary  function  is  other  than  computational. 
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The  primary  function  of  the  computers  are  to  monitor  and  control  devices"  (2:3).  In  addi¬ 
tion,  Embedded  Computer  Systems  (ECS)  generally  have  real-time  processing  constraints 
which  require  concurrent  computation.  Examples  of  ECS  in  the  DoD  are  large  systems, 
such  as,  the  flight  control  computers  for  the  F-15,  F-16,  and  F-lll.  These  systems  must 
be  reliable,  fault  tolerant,  and  easy  to  modify  over  their  long  life  span  (3:15). 

1.2  Statement  of  the  Problem 

The  biggest  problem  with  existing  models  of  concurrent /parallel  computation,  such 
as  Communicating. Sequential  Processes  (CSP)  and  Petri  Nets,  is  that  they  concentrate 
on  modeling  a  system’s  behavior  and  tend  to  ignore,  or  abstract  away,  performance  and 
timing  issues. 

It  is  important  to  specify  timing  requirements  in  the  system  specification  for  both 
the  software  and  hardware.  In  the  past,  the  system  specification  was  mainly  concerned 
with  describing  aspects  of  hardware  architecture  (e.g.,  speed  and  memory  capacity);  the 
software  timing  and  speed  were  simply  a  function  of  the  hardware  and  the  programmer's 
creativity.  Due  to  the  stringent  timing  requirements  of  real-time. systems,  it  is  imperative 
that  the  system  specification  include  both  hardware  and  software  constraints.  Performance 
and  timing  requirements  are  critical  issues  for  real-time  systems  and  must  be  included  in 
the  system  specification  to  determine  how  the  specified  Ada  runtime  environment  (RTE) 
impacts  a  given  desigmand  implementation. 

In  order  to  adequately  model  a  Mission  Critical  Computer  Resources  (MCCll)  sys¬ 
tem,  both  performance  and  behavior  must  be  described  by  a  comprehensive  formal  model. 
Such  a  model  of  Ada  tasking,  and  its  associated  RTE,  is  important  in  order  for  system 
designers  to  make  realistic  decisions  when  modeling  MCCR. systems.  Although  the  Ada 
language  tasking  constructs  are  compiler  independent,  actual  Ada  tasking  behavior  is  de¬ 
pendent  on  its  RTE.  It  is,  therefore,  important  for  the  systems  and  software  engineers 
to  be  aware  of  how  the  RTE  behaves  in  order  to  properly  design  these  complex  MCCR 
systems.  The  need  for  a  formal  model  of  Ada  tasking  and  its  associated  RTE  is  increasing 
as  Ada’s  usage  increases  in  concurrent/parallel  computing  systems. 
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Because  each  RTE  is  different,  an  Ada  tasking  model  needs  to  be  parameterized  to 
reflect  the  underlying  RTE.  Thus,  the  model  will  also  be  useful  in  determining  which  RTE 
best  suits  the  needs  of  a  particular  embedded  computer  system.  Alternately,  since  the 
selection  of  the  RTE  is  often  determined  by  computer  system  engineers,  the  model  may 
be  used  by  software  engineers  to  point  out  potential  problems  with  the  existing  RTE  and 
the  proposed  software  design. 

The  primary  goal  of  this  research  effort  is  to  analyze  and  develop  a  parameterized, 
formal  model  of  Ada  tasking  and  the  associated  RTE  that  incorporates  the  performance 
aspect.  This  goal  is  based  upon  the  hypothesis  that  such  a  formal  model  can  be  developed 
which  combines  graphical  and  mathematical  notations. 

1.3  Summary  of  Current  Knowledge 

Although  Ada  has  been  mandated  for  embedded  systems  (7:2),  there  is  doubt  among 
members  of  the  software  engineering  community  as  to  whether  Ada  is  capable  of  providing 
adequate  support  for  real-time  embedded  computer  systems  (M:49d-‘U)5).  Nevertheless, 
Ada  contains  the  tasking  facilities  and  low-level  I/O  necessary  for  implementing  real -time 
embedded  computer  systems.  However,  the  diversity  of  the  scheduling  algorithms  in  each 
RTE  causes  each  environment  to  be  different  and,  until  a  standard  RTE  exists,  software 
engineers  must  search  for  the  environment  that  is  appropriate  for  their  application  or  create 
a  design  that  is  appropriate  for  the  environment. 

Concurrent  programming  is  important  for  real-time  systems  because  it  is  possible  for 
events  to  arrive  that  must  be  handled  simultaneously.  Although  most  current  programming 
languages  only  allow  sequential  execution,  the  Ada  tasking  facility  allows  programs  to 
execute  concurrently.  “Tasking  is  an  important  aspect  of  many  embedded  systems  . . . 
However,  tasking  seems  to  have  been  neglected  in  most  languages  in  production  use  for 
such  systems”  (15:269).  The  concurrent  execution  of  tasks  also  makes  programs  more 
difficult  to  write  and  causes  the  RTE  to  be  more  difficult  to  implement. 

1.3.1  Ada  Tasking.  “A  task  is  the  scheduling  entity  in  a  system”  (2-1: The 
Ada  Language  Reference  Manual  (LRM)  defines  Ada  tasks  as  “entities  whose  executions 
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proceed  in  parallel”  (8:9-1).  Although  tasks  are  able  to  operate  concurrently,  there  is 
no  requirement  that  they  must  execute  at  the  same  time.  A  uniprocessor  system  may 
only  have  one  process  (or  task)  executing  at  any  given  time;  the  processes  take  turns 
executing  and,  although  only  one  task  is  actually  executing  at  a  time,  they  are  all  said  to 
be  “logically”  executing. 

Ada  tasks  operate  independently  except  when  they  need  to  synchronize  with  another 
task  at  which  time  they  are  said  to  “rendezvous”  (8:9-1)  (15:306).  One  task  calls  another 
task  by  issuing  an  entry  call  and  when  the  called  task  accepts  this  call,  the  two  tasks  are 
in  a  rendezvous  and  may  then  exchange  data.  After  completing  the  rendezvous,  the  t  asks 
again  execute  independently  and  asynchronously. 

It  is  possible  for  several  tasks  to  call  another  task  at  the  same  time.  When  this 
occurs,  the  calling  tasks  are  placed  into  an  entry  queue  and  the  called  task  will  rendezvous 
with  the  calling  tasks  in  the  queue  according  to  a  First-Gome-First-Served  scheduling 
algorithm  (8:9-9)  (15:276). 

1.3.2  Ada  Runtime  Environments.  When  the  first  programs  were  written  for 
mainframe  computers,  software  developers  created  code  segments  for  the  bare  computer 
hardware.  As  time  went  on,  the  software  engineers  agreed  on  basic  conventions  in  order 
that  their  code  might  work  together.  They  also  built  subroutines  which  could  be  reused 
from  application  to  application,  thus,  greatly  simplifying  programming.  These  conventions 
and  subroutines  allowed  the  software  engineer  to  abstract  one  level  away  from  the  bare 
machine  and  became  a  basic  RTE. 

At  this  point,  however,  the  bare  machine  was  still  accessible  to  the  programmer 
whose  code  would  interface  with  both  the  RTE  and  the  bare  machine.  This  allowed  each 
programmer  to  create  his  own  abstraction  of  the  computer.  As  time  went  on,  the  basic 
subroutines  of  the  RTE  were  refined  and  improved  with  the  machine-dependent  features 
becoming  the  operating  system  and  the  language-dependent  features  being  handled  by  the 
compiler. 

The  RTE  allows  the  programmer  to  abstract  away  low-level  implementation  details 
which  are  unique  to  each  machine.  The  convenience  of  using  the  RTE  offsets  the  slight 
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decrease  in  performance  due  to  the  overhead  of  the  RTE.  Each  RTE  is  developed  for  a 
specific  machine;  therefore,  an  application  tailored  for  one  machine  may  perform  much 
differently  on  another  machine;  this  is  due  entirely  to  its  RTE  (1:11). 

Ada  is  defined  in  the  LRM  and  any  Ada  RTE  must  comply  with  the  requirements 
therein.  However,  the  LRM  allows  great  flexibility  in  how  the  RTE  will  support  Ada  and 
since  there  is  currently  no  standard  Ada  RTE,  there  can  be  many  interpretations  and 
differing  Ada  RTEs  (1:14). 

1.S.3  Scheduling  Algorithms.  A  scheduler  decides  the  order  of  execution  for 
tasks  on  a  central  processing  unit  (CPU),  entry  queue,  or  input/output  processor  (IOP). 
The  CPU  and  entry  schedulers  are  important  within  Ada  task  scheduling.  Tasks  may 
be  periodic  or  aperiodic,  independent  or  synchronous.  Periodic  tasks  repeat  after  a  fixed 
interval  of  time,  whereas,  aperiodic  tasks  occur  only  once,  or  at  random  intervals.  Periodic 
tasks  have  a  specified  repetition  rate  called  the  frequency  or  request  rate.  There  are  varying 
degrees  of  synchronous  tasks;  synchronous  tasks  may  be  totally  dependent  on  other  tasks 
or  they  may  only  need  to  exchange  data  occasionally.  As  mentioned  previously.  Ada 
tasks  exchange  data  by  synchronizing  in  a  rendezvous.  Independent  tasks  do  not  need  to 
exchange  information  with  other  tasks  and,  therefore,  do  not  rendezvous  with  other  tasks. 

Deadlock,  starvation,  and  task  set  performance  are  important  issues  for  scheduling 
algorithms.  Starvation  occurs  when  a  task  or  group  of  tasks  is  not  allowed  to  execute. 
Performance  is  a  measurement  of  throughput  and  turnaround  time.  Throughput  measures 
how  many  tasks  complete  in  a  given  time  period.  Turnaround  time  measures  how  long  a 
particular  task  takes  to  complete.  Each  scheduling  algorithm  has  different  performance; 
some  algorithms  that  allow  starvation  may  actually  have  better  average  performance  than 
algorithms  that  do  not  allow  starvation  (23:Ch  4). 

Some  examples  of  possible  scheduling  algorithms  are:  First-Come-First-Servc  (FCFS), 
Shortest-Job-First  (SJF),  Round  Robin  (RR),  and  Rate  Monotonic  (RM),  and  each  of 
these  are  summarized  below. 
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1.3.3. 1  First-Come-First-Serve  (FCFS).  The  FCFS  scheduling  algo¬ 
rithm  is  the  easiest  to  implement.  New  tasks  are  placed  at  the  tail  of  the  ready  queue  and 
are  allocated  from  the  head  of  the  queue.  In  FCFS,  all  tasks  are  of  equal  priority  which 
causes  performance  to  be  poor  because  the  average  waiting  time  is  not  minimized  (18:106). 
The  benefit  of  FCFS  is  that  it  will  not  allow  starvation. 

1.5.3.2  Shortest  Job  First  (SJF).  The  SJF  scheduling  algorithm  allocates 
the  task  with  the  smallest  estimated  execution  time  or  “burst.”  If  two  tasks  have  the  same 
burst  time,  then  FCFS  scheduling  is  used.  There  is  no  way  of  knowing  what  the  actual 
length  of  the  next  burst  will  be  without  future  knowledge;  therefore,  the  next  burst  will 
be  estimated  upon  its  past  performance.  SJF  gives  the  minimum  average  waiting  time  for 
a  set  of  tasks  since  it  chooses  a  short  task  before  a  long  task.  This  will  decrease  the  short 
task’s  wait  time  more  than  it  will  increase  the  long  task’s  wait  time.  Thus,  SJF  gives  a 
lower  average  waiting  time.  A  problem  with  this  method  is  that  tasks  with  large  bursts 
may  starve  since  the  algorithm  constantly  chooses  the  task  with  the  shorter  burst  times 
(23:180). 

Additionally,  the  SJF  algorithm  can  be  preemptive  or  non-proem ptive.  A  preemptive 
SJF  allows  the  task  currently  running  to  be  interrupted  when  a  new  task  arrives  in  the 
queue  which  has  a  smaller  burst  time.  A  non-preemptive  SJF  allows  the  task  running  on 
the  processor  to  execute  until  it  completes. 

1.3. 3.3  Round  Robin  (RR).  The  RR  scheduling  algorithm  is  similar  to 
FCFS  except  that  it  preempts  an  executing  task  after  allowing  it  to  run  for  a  specified 
time  or  quantum.  It  then  places  the  task  at  the  end  of  the  ready  queue.  This  algorithm 
is  often  used  on  uniprocessor  systems  in  order  to  give  the  illusion  that  all  the  tasks  are 
operating  concurrently.  The  RR  algorithm  does  not  allow  starvation.  If  the  time  quantum 
is  too  large,  the  RR  algorithm  behaves  like  the  FCFS  algorithm  mentioned  above. 

1.3.3. 4  Rate  Monotonic  (RM).  The  RM  scheduling  algorithm,  used  for  a 
set  of  independent  periodic  tasks,  selects  tasks  based  upon  their  period.  Tasks  with  shorter 
periods  are  scheduled  before  tasks  with  longer  periods.  “A  major  advantage  of  using  the 
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rate  monotonic  algorithm  is  that  it  allows  us  to  separate  logical  correctness  from  timing 
correctness  concerns”  (22:7). 

I.8.4  Ada  RTE  Schedulers,  a  real-time  scheduler  assigns  an  ordering  (sched¬ 
ule)  to  a  set  of  tasks  in  order  to  meet  timing,  precedence,  or  resource  requirements  of 
real-time  systems.  An  Ada  RTE  requires  two  schedulers:  one  to  schedule  the  tasks  to  run 
oh  the  processors;  and  one  to  schedule  the  synchronization  points  for  each  entry  queue. 
These  algorithms  need  not  be  the  same. 

Processor  scheduling  can  use  any  scheduling  discipline;  however,  certain  algorithms 
will  be  more  efficient  for  specific  applications.  Most  Ada  RTEs  use  FCFS  or  RR  (26:5-15). 

Each  entry  point  has  its  own  queue  and  the  entry  scheduler  must  use  the  FCFS 
algorithm,  as  illustrated  by  the  following  quote  from  the  LRM. 


If  several  tasks  call  the  same  entry  before  a  corresponding  accept  statement  is 
reached,  the  calls  are  queued;  there  is  one  queue  associated  with  each  entry. 

Each  execution  of  an  accept  statement  removes  one  call  from  the  queue.  The 
calls  are  processed  in  the  order  of  arrival  (8:9-9). 

Although  the  FCFS  schedule  does  not  produce  the  shortest  schedules  (i.e.,  best 
performance),  it  is  non-preemptive.  This  allows  the  code  within  the  accept  statement  to 
be  treated  as  a  critical  section.  A  critical  section  protects  a  shared  data  area  and  only 
one  task  should  have  access  to  this  section  at  a  time  or  data  may  be  lost  or  overwritten 
(23:83).  Once  an  entry  is  selected,  it  must  be  allowed  to  continue  executing  until  it  is 
completed.  No  other  accept  statements  for  the  tasks  in  the  rendezvous  will  be  allowed  to 
execute  until  the  current  rendezvous  is  complete.  Preemptive  schedulers,  such  as,  the  RR 
and  preemptive  SJF,  are  not  allowed  because  they  may  interrupt  a  task  while  in  a  critical 
section. 

1.4  Scope 

A  formal  model  of  Ada  tasking  is  expected  to  generate  performance  statistics  for  a 
set  of  Ada  tasks  based  upon  specific  runtime  parameters,  such  as,  the  scheduling  algorithm 
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and  task  execution  times.  The  benefit  of  modeling  the  performance  is  that  software  engi¬ 
neers  will  know  whether  or  not  their  design  meets  the  required  performance  criteria  before 
implementing  the  code.  If  the  criteria  are  not  met,  they  can  modify  their  design  until  it 
does  meet  the  requirements  or  find  a  RTE  that  meets  the  requirements. 

The  model  incorporates  the  Ada  language  constructs  detailed  in  the  Ada  LRM  (e.g., 
entries,  accepts,  delays,  priorities)  (8:Ch  9)  and  includes  the  sequence  of  events  and  timing 
information.  The  actual  model  was  developed  mathematically  and  is  based  on  constructs 
in  queueing  theory,  set  theory,  and  real-time  scheduling.  Because  of  its  mathematical 
nature,  this  model  may  be  difficult  for  non-technical  people  to  understand;  therefore,  a 
future  research  effort  will  produce  a  rapid  prototyping  environment  that  will  perforin  the 
mathematics  and  provide  a  simplified  user  interface.  The  ultimate  goal  of  future  research 
will  be  to  create  an  automated  toot  that  will  return  a  trace  of  events  and  performance 
statistics. 

The  basic  hypothesis  of  this  research  was  that  a  formal  model  of  Ada  tasking  could  be 
developed,  and  that  the  model  could  be  used  to  help  develop  design  analysis  environments 
for  distributed  real-time  software  systems  requiring  Ada  as  their  target  language.  Thus, 
given  a  specification  for  such  a  system,  the  design  analysis  environment  can  be  used  to 
obtain  the  information  needed  to  support  Ada  software  design  decisions.  No  effort  was 
made  to  design  and  implement  a  design  analysis  environment  in  this  research  effort. 

1.5  Approach  and  Methodology 

In  order  to  develop  the  parameterized  model,  a  literature  search  was  conducted  to 
determine  how  and  why  the  Ada  tasking  constructs  were  defined  (8:Ch  9)  (15:Ch  13) 
and  then  a  survey  was  conducted  of  existing  types  of  formal-based  models  of  paral¬ 
lel/distributed  computation,  e.g.,  Petri  Nets  and  CSP.  Additionally,  queueing  theory  and 
real-time  scheduling  were  investigated.  Finally,  current  behavioral  models  of  real-time 
software  analysis  and  design  methodologies  such  as  Real-Time  Structured  Analysis  (RTS  A) 
and  the  Design  Approach  for  Real-Time  Systems  (DARTS)  were  explored.  The  goal  was 
to  ultimately  incorporate  the  formal  tasking  model  into  one  of  the  existing  methodologies 
and,  in  fact,  the  DARTS  methodology  was  selected. 
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After  the  initial  research,  the  results  were  generalized  into  an  Ada  Tasking  Model 
which  synthesized  the  applicable  concepts  gleaned  from  the  current  models  and  methods 
mentioned  above.  The  initial  model  provided  a  broad  base  for  the  final  parameterized 
model  which  was  developed  after  several  iterations. 

Typically,  a  software  development  life  cycle  contains  three  basic  phases:  a  software 
requirements  analysis  phase,  a  software  design  phase,  and  a  low-level  software  design  and 
implementation  phase.  The  model  developed  for  this  research  is  part  of  the  software  design 
phase  and  is  concerned  solely  with  the  Model  Design  Performance  block  in  Figure  1.1. 


Figure  1.1.  Software  Development  Life  Cycle 
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This  research  document  is  organized  as  follows:  Chapter  II  describes  formal  mOdel- 
ing;  Chapter  III  defines  the  top-level  design  for  a  proposed  performance  model;  Chapter  IV 
contains  a  description  of  the  detailed  design  of  the  proposed  model;  Chapter  V  discusses 
validating  the  model;  Chapter  VI  gives  recommendations  for  further  research.  There  are 
three  appendices  attached:  Appendix  A  contains  a  list  of  the  acronyms  used  in  this  docu¬ 
ment;  Appendix  B  contains  a  detailed  Structured  Analysis  and  Design  Technique  (SADT) 
description  of  the  Ada  tasking  model;  and  Appendix  C  contains  the  programs  used  to 
validate  the  model. 
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II.  Modeling 


As  software  system  requirements  become  more  complex,  software  engineers  need  to 
carefully  design  their  systems  to  ensure  that  the  system  adequately  meets  all  its  timing 
and  behavior  requirements.  Modeling  allows  a  designer  to  create  an  abstraction  of  the 
system  and  add  detail  in  an  iterative  fashion  as  the  requirements  become  more  clearly  un¬ 
derstood.  Due  to  the  complexity  of  real-time  system  requirements,  it  is  extremely  difficult 
for  a  designer  to  initially  understand  the  entire  system  and  how  its  components  inter¬ 
act.  According  to  Pritsker,  u[t]he  entire  model  building  approach  is  performed  iteratively” 
(20:5).  By  modeling  the  system  with  increasing  levels  of  complexity,  a  designer  will  gain  a 
better  understanding  of  the  requirements  and  have  more  confidence  that  the  design  meets 
those  requirements. 

Coding  is  ah  expensive  process  and,  once  code  has  been  written,  many  managers  are 
not  willing  to  throw  it  away  and  start  Over  if  problems  are  found  with  the  design.  Instead, 
they  will  encourage  the  programmers  to  manipulate  the  existing  code  to  make  it  fit  the 
new  scenario.  One  way  to  save  time,  money,  and  wasted  effort,  when  designing  software, 
is  to  first  develop  the  top-level  design  and  then  create  a  model  of  that  design.  The  model 
will  allow  a  designer  to  abstract  away  the  low-level  details  until  the  system  requirements 
are  better  understood.  However,  it  must  be  remembered  that  an  inherent  problem  with 
models  is  that  simplifying  assumptions  must  be  made  in  order  to  abstract  away  unwanted 
or  unnecessary  detail.  These  assumptions  must  be  valid  or  they  invalidate  the  model  since 
the  model  ho  longer  accurately  reflects  the  intended  system. 

2il  Definition  of  Models 

Models  for  a  software  design  are  much  more  flexible  than  the  code  for  that  design; 
therefore,  changes  can  more  easily  be  made  to  the  model.  This  flexibility  encourages 
the  designer  to  create  the  model  in  stages;  ultimately  creating  a  software  design  model 
which  accurately  portrays  the  real  system  and  meets  the  stated  requirements.  Modeling 
also  allows  a  designer  to  compare  multiple  approaches  to  solving  a  problem.  Therefore, 
a  designer  can  confidently  choose  to  implement  the  design  which  represents  the  optimum 
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solution.  Once  the  model  has  been  used  to  analyze  a  proposed  software  design,  the  code 
can  be  written  and  the  designer  will  have  confidence  that  the  code  will  accurately  reflect 
the  requirements  of  the  System. 

There  are  several  types  of  models:  descriptive  (natural  language);  physical  (actual 
representation);  symbolic  language  (mathematical);  graphical;  and  procedural  (simulation) 
(9:6).  The  models  of  interest  to  this  research  are  the  symbolic  and  graphical  models.  The 
symbolic  models  are  concise,  formal  models  which  mathematically  describe  a  system’s 
behavior.  Graphical  models  describe  the  behavior  of  a  system  pictorially. 

This  chapter  presents  an  overview  of  the  following  formal  models:  Communicating 
Sequential  Processes  (CSP)  (13),  Petri  nets  (19),  and  Unbounded  Nondeterministic  Iter¬ 
ative  Transformations  (UNITY)  (4).  Additionally,  three  graphical  models  are  described: 
Real-Time  Structured  Analysis  (RTSA)  (2),  Design  Approach  for  Real-Time  Systems 
(DARTS)  (11),  and  Structured  Analysis  and  Design  Technique  (SADT)  (12);  and  the 
top-level  design  of  the  Ada  tasking  model  is  introduced. 

2,2  Formal  Models  of  Parallel/Distributed  Computation 

2.2.1  Communicating  Sequential  Processes  (CSP).  CSP,  a  formal  model 
developed  by  C.A.R.  Hoare(13),  can  be  used  to  model  event  driven  systems.  CSP  had  a 
strong  influence  upon  the  design  of  the  Ada  rendezvous;  however,  while  the  rendezvous  in 
Ada  is  one-sided,  or  asymmetric,  the  communication  between  tasks  in  CSP  is  symmetric 
(15:306-308).  The  asymmetry  of  Ada  task  communication  allows  one  task  to  call  another 
task,  such  that,  the  called  task  does  not  know  the  name  of  the  task  which  is  calling  it.  The 
result  of  the  asymmetry  is  that  entry  queues  may  be  formed. 

Processes  in  CSP  can  execute  concurrently  by  communicating  via  message  passing; 
although  processes  in  CSP  can  execute  concurrently,  only  one  event  is  allowed  to  occur  at 
a  given  time.  Hence,  it  is  not  possible  to  determine  if  two  events  happened  simultaneously. 
If  strict  concurrency  is  necessary,  it  must  be  modeled  as  a  single-event  occurrence. 

2.2.2  Petri  Nets.  Petri  nets  combine  graphical  and  mathematical  notations.  As 
with  CSP,  it  is  not  possible  to  model  simultaneous  events  (19:37).  The  execution  of  a  Petri 
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net  is  hondeterministic  (19:36)  and  general  Petri  nets  abstract  away  timing  issues:  “There 
is  no  inherent  measure  of  time  or  the  flow  of  time  in  a  Petri  net”  (19:35).  In  addition,  a 
major  disadvantage  of  Petri  nets  is  that  the  complexity  of  the  model  increases  with  the 
size  of  the  system.  This  increased  complexity  means  that  they  tend  to  be  useful  only  for 
manually  modeling  small  systems. 

2.2.3  UNITY.  UNITY,  developed  by  Chandy  and  Misra,  is  a  “computational 
model  and  a  proof  system”  (4:8).  The  goal  of  UNITY  is  to  mathematically  design  programs, 
at  a  high-level,  which  are  free  from  implementation  issues,  such  as  computer  architecture 
and  language,  and  whose  correctness  can  be  proven.  The  disadvantages  of  UNITY  are 
that  it  is  hard  to  understand  and  proving  that  the  high-level  UNITY  program  meets  the 
requirements  does  not  mean  that  the  program  implementation  meets  the  requirements. 
Another  disadvantage  of  UNITY  is  that  it  abstracts  away  timing  issues  and  does  not  allow 
a  designer  to  specify  a  control  sequence.  Thus,  timing  issues  cannot  be  modeled  in  UNITY. 

The  formal  models  mentioned  in  this  section,  i.e.,  CSP,  Petri  nets,  and  UNITY,  are 
adequate  for  modeling  the  behavior  of  the  system;  however,  they  ignore  timing  require¬ 
ments  and  are  difficult  to  apply.  The  next  section  discusses  three  graphical  models. 

2.3  Graphical  Models 

2.3.1  Real-Time  Structured  Analysis.  RTSA,  a  variation  of  structured  anal¬ 
ysis  and  design  developed  by  Yourdan  and  DeMarco,  is  used  during  the  software  require¬ 
ments  analysis  phase.  (See  Fjgure  1.1  for  the  Software  Life  Cycle.)  RTSA  extends  the 
traditional  data  flow  diagrams  to  include  timing  information  through  the  use  of  control 
flows  and  transforms.  The  designer  creates  the  data  flow/control  flow  diagrams  during 
RTSA  and  supplements  the  diagrams  by  natural  language  or  state  transition  diagrams. 
The  disadvantage  of  RTSA  is  that  it  has  no  formal  mathematical  basis  that  can  be  used 
to  analyze  the  resulting  RTSA  design. 


2.3.2  Design  Approach  for  Real-Time  Systems.  DARTS  is  also  an  extension 
of  structured  analysis  and  design.  Using  a  RTSA  input,  DARTS  focuses  on  decomposing 


a  system  into  a  set  of  concurrent  tasks  and  models  the  inter-task  communication.  After 
DARTS  is  completed,  each  subsystem  has  been  divided  into  sets  of  tasks  which  operate 
concurrently  and  each  task  has  a  single  thread  of  control.  However,  DARTS  does  not 
specify  the  timing,  hardware,  or  RTE  requirements,  and  as  with  RTS  A,  the  DARTS  design 
has  no  mathematical  basis  for  evaluating  the  quality  of  the  design. 

DARTS  is  performed  after  the  software  requirements  analysis  has  been  completed 
and  it  has  four  steps  (represented  within  the  dashed  lines  in  Figure  2.1): 

•  define  the  interfaces  between  the  subsystems; 

•  structure  the  subsystems  into  parallel  tasks; 

•  define  the  interfaces  between  the  tasks;  and 

•  design  individual  tasks  using  structured  design. 

2.3. 3  Structured  Analysis  and  Design  Technique1.  SADT  (12),  as  the  name 
suggests,  is  also  a  variation  of  structured  analysis  and  is  used  during  the  software  require¬ 
ments  phase.  (See  Figure  1.1  for  the  Software  Life  Cycle.)  As  with  RTSA  and  DARTS, 
an,  SADT  design  has  no  formal  mathematical  basis  and  cannot  be  proven  mathematically. 
SADT  is  described  here  in  detail  because  SADT  was  used  in  the  requirements  analysis, 
specification,  and  design  of  the  developed  Ada  tasking  model. 

A  generic  SADT  diagram  is  shown  in  Figure  2.2. 

2.3. 3.1  Interfaces;  The  basic  element  in  SADT  is  the  function  which  de¬ 
scribes  a  process  or  action  and  is  represented  by  a  box.  The  arrows  define  interfaces  and 
are  described  in  the  following  quote. 

Interfaces  are  represented  by  arrows  entering  or  leaving  the  box.  The  type  of 
interface  is  indicated  by  the  side  of  the  rectangle  to  which  it  is  connected  . . . 
input  arrows  enter  the  left  side  of  the  function  box,  output  arrows  leave  the 
right  side  of  the  box,  control  arrows  enter  the  top  of  the  box,  and  mechnnism 

lSADT  is  a  trademark  of  SofTech. 
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Figure  2.2.  Generic  SADT  Diagram 

arrows  either  enter  or  leave  the  bottom  of  the  box.  The  function  is  viewed  as 

transforming  its  inputs  into  outputs  under  the  guidance  of  its  controls.  (12:7) 

SADT  descriptions  do  not  impose  timing  requirements  so  the  arrows  merely  rcpieseni 
constraints;  a  function  cannot  commence  unless  its  control  and  inputs  are  available.  "The 
functions  represent  processes  that  must  occur,  but  may  in  fact  occur  simultaneously.  The 
arrows  represent  data  or  information  produced  by  or  needed  by  a  function.  They  should 
not  be  viewed  as  flows  or  sequences  of  operations”  (12:7). 

Additionally,  every  function  requires  at  least  one  control  arrow  and  one  output  arrow, 
regardless  of  whether  or  not  there  are  any  input  or  mechanism  arrows.  The  mechanism 
arrows  “indicate  a  means  of  performing  the  function”  (12:7). 

2.3. 3.2  Hierarchy  of  Numbering.  SADT  has  a  special  numbering  system 
which  denotes  the  hierarchical  level  of  decomposition.  Each  function  box  label  begins  with 
an  “A”  which  stands  for  “Activity.”  The  top-level,  or  environment  model,  is  labeled  as 
level  A-0  and  contains  a  single  box.  This  box  shows  the  interconnection  of  the  system 
to  be  modeled  with  its  environment.  The  first  level  of  decomposition  is  labeled  AO  and 
represents  the  major  subfunctions  of  the  system.  Each  of  the  boxes,  or  functions,  at  level 
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AO  are  sequentially  labeled  Al,  A2,  etc.  In  turn,  the  functions  on  the  level  A1  diagram 
are  labeled  All,  A12,  etc.  This  numbering  system  facilitates  determining  the  level  of  the 
diagram  and  maintaining  consistency  between  the  levels. 

2.4  Deficiencies  of  Real-Time  Models 

The  formal  models  described  in  Section  2.2  model  the  behavior  of  the  system  but 
are  either  too  complex  to  use,  ignore  timing  requirements,  or  both.  The  graphical  models 
described  in  Section  2.3  lack  the  formalism  of  the  formal  models  which  is  important  when 
analyzing  the  design. 

Because  real-time  systems  have  these  timing  constraints,  in  addition  to  behavioral 
constraints,  a  formal  software  design  analysis  model  is  required  which  incorporates  per¬ 
formance,  timing,  and  behavioral  constraints.  Consider,  for  example  the  DARTS  design 
methodology,  the  box  labeled  Model  Design  Performance  in  Figure  2.1  is  an  additional 
step  added  to  DARTS  which  deals  with  solving  these  deficiencies,  and  the  object  of  this 
research  is  to  analyze  the  feasibility  of  constructing  such  a  model.  Specifically,  the  next 
chapter  introduces  the  top-level  design  for  the  design  performance  model. 


III.  Design  of  the  Ada  Tasking  Model 


This  chapter  describes  the  top-level  design  of  the  performance  model  of  Ada  tasking. 
The  Model  Design  Performance  activity  in  Figure  3.1  is  performed  after  the  initial  DARTS 
design  has  been  accomplished.  If  application  of  the  performance  model  shows  that  the 
software  design  fails  to  perform  as  required,  then  the  software  design  must  be  modified 
or  reaccomplished  and  the  performance  model  reapplied.  This  feedback  loop  continues 
until  such  time  as  it  is  determined  the  software  design  satisfactorily  meets  its  performance 
requirements. 

3.1  Model  Design  Performance 

Figure  3.1  is  an  SADT  diagram  representing  the  environment,  or  A-0  level  diagram. 
The  function,  Model  Design  Performance ,  is  an  extension  to  DARTS  and  is  applied  after 
the  initial  DARTS  design  has  been  completed.  Model  Design  Performance  requires  that  the 
software  design  first  be  produced  using  DARTS.  In  addition,  Model  Design  Performance 
requires  the  non-functional  requirements  and  scheduling  information  about  the  RTE. 

The  Model  Design  Performance  activity  is  decomposed  into  two  functions:  Define 
Task  Performance  Requirements  (Al)  and  Model  Ada  Tasking  (A2).  Note  that  the  output 
arrow,  Performance  Data ,  has  been  decomposed  into  schedulable,  task  schedule,  entry 
trace  and  performance  stats.  The  decomposition  for  Model  Design  Performance  is  shown 
in  Figure  3.2,  representing  the  AO  level,  and  the  activities  Al  and  A2  are  described  in  the 
Sections  3.2  and  3.3. 

3.2  Define  Task  Performance  Requirements 

The  function,  Define  Task  Performance  Requirements ,  has  three  interface  arrows:  the 
control  arrow  is  the  software  design;  the  input  arrow  is  the  non-functional  requirements; 
and  the  output  arrow  is  the  task  information  which  includes  the  task  names,  periods, 
execution  times,  etc.  (For  more  detail  on  the  task  information,  see  the  data  dictionary 
in  Appendix  B.)  Note  that  there  is  no  mechanism  for  this  function.  The  remainder  of 
this  research  concentrates  on  developing  the  Ada  Tasking  Modei  (level  A2)  with  certain 
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Figure  3.1.  Environment  Model 

assumptions  made  about  the  outputs  of  Al.  A  more  comprehensive  examination  of  defining 
task  performance  requirements  (Al)  will  be  accomplished  in  follow-on  research. 

3.3  Model  Ada  Tasking 

The  function  A2,  Model  Ada  Tasking ,  has  six  interface  arrows:  one  mechanism,  four 
outputs,  and  one  control.  The  mechanism  arrow  is  the  RTE.  The  four  output  arrows  are: 
schedulable,  which  is  a  Boolean  flag  that  tells  the  designer  if  the  tasks  can  be  scheduled 
based  upon  the  given  RTE  and  task  information;  task  schedule ,  which  is  a  possible  schedule 
based  upon  the  scheduling  information  from  the  RTE  mechanism  and  the  task  information; 
entry  trace,  which  is  a  possible  sequence  of  entry  points  based  upon  the  task  schedule;  and 
performance  statistics,  which  are  statistics  describing  the  design  performance.  The  control 
arrow  is  the  task  information  which  is  the  same  as  the  output  arrow  from  function  Al. 

The  task  information  includes  the  task  name,  execution  time,  period,  etc.  In  order 
to  schedule  a  group  of  tasks,  the  task  execution  time  ( E, )  and  period  (T,)  must  be  known. 
These  values  are  used  to  determine  each  load  factor  which  is  the  execution  time  of  a  task 
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Figure  3.2.  Level  AO 


divided  by  its  period  (§{)■  Each  processor  may  only  execute  a  set  of  tasks  if  the  sum  of 
their  load  factors  is  less  than  1,  where  1  represents  100%  utilization  of  the  processor. 

The  basic  components  of  the  Ada  tasking  model  (shown  in  Figure  3.3)  are  Deter¬ 
mine  Unschedulability,  Create  Schedule ,  and  Model  Entry  Calls.  Functions  A21  and  A22 
determine  if  the  given  set  of  tasks  are  schedulable  and,  if  so,  a  schedule  is  found.  Func¬ 
tions  A21-A23  are  summarized  below;  the  details  of  these  functions  have  been  placed  in 
Appendix  B. 
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Figure  3.3.  Level  A2 


3.S.1  Determine  Unschedulability.  Function  A21,  Determine  Unschedulabil¬ 
ity,  has  four  interface  arrows:  a  control  arrow  labeled  task  info’,  an  input  arrow  labeled 
num  processors ;  and  two  output  arrows  labeled  bounds  and  schedulable.  The  interface  ar¬ 
rows,  task  info  and  schedulable,  were  defined  above.  The  interface  arrow,  num  processors , 
refers  to  the  number  of  processors  which  will  be  used  in  the  target  machine  for  the  system 
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the  designer  is  modeling.  The  interface  arrow,  bounds ,  is  an  integer  range  which  defines 
the  upper  and  lower  bound  on  the  number  of  processors  required  for  the  target  machine. 
If  num  processors  is  within  this  range  and  if  schedulable  is  true,  then  the  designer  can 
proceed  to  Level  A22.  If  either  of  these  conditions  is  false,  then  the  designer  must  either 
redesign  the  software  tasks  (i.e.,  reapply  DARTS)  or  change  the  number  of  processors  in 
the  system  specification.  Redesigning  the  software  is  the  logical  first  step;  changing  the 
system  specification  should  only  be  done  as  the  last  resort. 

Note  that  function  A21  only  determines  if  the  given  set  of  tasks  cannot  be  scheduled 
and  does  not  guarantee  that  the  tasks  are,  in  fact,  schedulable.  Hence,  the  algorithm  used 
to  determine  unschedulability  is  a  necessary  condition,  not  a  sufficient  condition.  The  only 
way  to  know  for  certain  if  the  tasks  are  schedulable  is  to  apply  function  A 22  and  actually 
create  a  schedule  of  the  tasks. 

3.3.2  Create  Schedule.  Function  A22,  Create  Schedule,  is  performed  after  the 
design  passes  Level  A21.  This  function  has  five  interface  arrows:  a  control  arrow  labeled 
schedulable ;  two  input  arrows  labeled  num  processors  and  task  info\  a.  mechanism  arrow 
labeled  scheduler  info-,  and  an  output  arrow  labeled  task  schedule.  The  interface  arrows, 
labeled  schedulable,  num  processors  and  task  info  axe  defined  above.  The  mechanism  arrow, 
scheduler  info,  refers  to  the  type  of  task  scheduler  used  in  the  RTE.  The  output  arrow, 
task  schedule,  is  the  schedule  of  tasks  which  were  developed  in  the  DARTS  design. 

3.3.3  Model  Entry  Calls  Function  A23,  Model  Entry  Calls,  has  four  interface 
arrows:  a  control  arrow  labeled  task  schedule  which  is  a  schedule  of  the  tasks  which  were 
developed  in  the  DARTS  design;  an  input  arrow  labeled  task  info  which  includes  the 
task  names,  periods,  execution  times,  etc.;  and  two  output  arrows  labeled  entry  trace  and 
performance  stats.  The  entry  trace  is  a  sequence  of  the  entry  points  and  the  performance 
stats  are  statistics  describing  the  design  performance. 

The  next  chapter  describes  Model  Entry  Calls  in  detail  after  providing  background 
information  on  Ada  entry  points  and  arrival  distributions. 
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IV.  Model  Entry  Calls 


4-1  Ada  Entry  Points 

There  are  two  maun  distinctions  among  entry  points.  The  first  distinction  is  between 
single  entries  and  entry  families.  A  single  entry  queues  its  calls  according  to  the  FCFS 
discipline.  An  entry  family  queues  its  calls  according  to  the  index  associated  with  the  call, 
where  the  index  can  denote  the  priority  of  the  call.  Entry  families  represent  a  hierarchy 
of  queues;  each  index  has  its  own  entry  queue  which  uses  the  FCFS  discipline.  Thus,  calls 
can  be  accepted  from  the  queues  in  the  order  of  their  index  which  allows  a  priority  scheme 
to  be  developed. 

The  second  distinction  is  among  timed,  conditional,  and  simple  entries.  A  timed  entry 
allows  balks;  this  call  is  cancelled  if  the  rendezvous  does  not  begin  within  the  specified  time. 
A  conditional  entry  is  a  special  case  of  the  timed  entry  with  the  time  limit  set  to  zero. 
The  call  is  cancelled  unless  the  rendezvous  can  occur  immediately.  The  simple  entry  can 
be  thought  of  as  a  timed  entry  with  a  time  limit  of  infinity.  A  simple  call  is  not  revoked 
once  it  has  been  issued. 

Combining  the  above  categories  gives  six  types  of  entry  points:  single  timed,  single 
conditional,  single  simple,  family  of  timed,  family  of  conditional,  and  family  of  simple 
entries.  Table  4.1  describes  the  different  types  of  entries  and  how  they  will  be  modeled. 

4.2  Modeling  Assumptions 

The  interarrival  and  service  times  will  be  modeled  by  the  exponential  distribution 
based  on  the  following  assumptions: 

•  the  current  arrival/service  time  is  independent  of  the  last  arrival/service;  and 

•  the  arrival/service  time  is  independent  of  the  number  in  the  entry  queue. 

These  assumptions  appear  to  be  valid  for  the  Ada  Tasking  Model  because  the  time 
since  the  last  arrival  and  the  time  in  service  refer  to  real  or  continuous  time  and  not 
to  computer  processing  time  which  may  be  affected  if  the  task  is  swapped  out  of  the 
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Table  4.1.  Modeling  Entry  Queues 
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processor.  Additionally,  these  assumptions  are  frequently  used,  as  demonstrated  by  the 
following  quote  from  Trivedi  (25:114): 


Thus  the  following  random  variables  will  often  be  modeled  as  exponential: 

1.  Time  between  two  successive  job  arrivals  to  a  computing  center  (often  called 
interarrival  time). 

2.  Service  time  at  a  server  in  a  queuing  network;  the  server  could  be  a  resource 
such  as  the  CPU,  I/O  device,  or  a  communication  channel. 

Therefore,  the  entry  queues  will  be  modeled  using  M/M/1  queues.  The  term 
“M/M/1”  comes  from  Kleinrock  (16)  who  uses  the  notation  “A/B/m/Iv/M”  to  describe 
queueing  systems.  The  “A”  represents  the  arrival  distribution  and  “B”  represents  the 
service  distribution.  The  following  quote  from  Kleinrock  further  explains  the  notation. 


m-Server  queue  with  Aft)  and  Bfx)  identified  by  A  and  B,  respectively,  with 
storage  capacity  of  size  K,  and  with  customer  population  of  size  M  (if  any  of 
the  last  two  descriptors  are  missing  they  are  assumed  to  be  infinite)  (16:399) 


In  this  instance,  the  queues  are  single  servers  with  the  interarrival  distribution,  Aft), 
and  service  distribution,  B(x).  Both  of  these  distributions  are  described  as  M  which  means 


that  they  denote  the  exponential  distribution.  The  Probability  Distribution  Function 
(PDF)  of  the  exponential  distribution  is  (16:65): 

X(t)  s  1  -  e~Xi  for  t  >  0  (4.1) 

The  Probability  Density  Function  (pdf)  is,  therefore  (16:65): 

x(t)  =  s  =«  Ae“At  for  t>  0  (4.2) 

at 

The  exponential  distribution  is  especially  interesting  due  to  its  memoryless  property 
which  states  that,  “the  past  history  of  a  random  variable  that  is  distributed  exponentially 
plays  no  role  in  predicting  its  future”  (16:66).  This  property  is  represented  by  the  following 
equation,  where, 


P[X  <t  +  s\X>s]  =  P[X  <  *]  (4.3) 

Thus,  the  arrival  time  is  independent  of  when  the  last  arrival  occurred  and  the  service 
time  is  independent  of  the  time  already  spent  in  service.  Another  assumption  is  that  the 
system  is  in  steady  state. 

The  assumption  of  M/M/1  queues  also  keeps  the  solution  of  the  queueing  network 
tractable,  as  illustrated  by  the  following  quote: 


When  one  relaxes  the  Markovian  assumptions  on  arrivals  and/or  service  times, 
then  extreme  complexity  in  the  interdeparture  process  arises  not  only  from  its 
marginal  distribution,  but  also  from  its  lack  of  independence  on  other  state 
variables.  (16:155) 


4-2-1  Arrival  Distributions.  Calls  arrive  at  the  entry  queues  according  to  either 
a  random  or  general  distribution.  (For  the  purposes  of  this  research,  a  general  distribution 
refers  to  a  non-random  distribution,  e.g.,  a  deterministic  distribution.)  In  addition,  calls 
may  or  may  not  repeat.  Repeating,  or  cyclic,  calls  may  occur  with  either  a  random  or 
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general  distribution,  both  of  which  may  repeat  at  a  known  frequency.  Non-repeating  calls 
are  also  based  upon  random  or  general  distributions  and  can  be  thought  of  as  repeating 
calls  with  an  infinite  period. 

Random  calls  can  be  made  from  either  the  hardware  or  the  software;  general  calls  can 
only  be  made  from  the  hardware  because  Ada  offers  no  timing  guarantees  for  the  software 
entry  calls.  Additionally,  even  though  the  hardware  can  make  entry  calls  at  a  specified 
time,  the  Ada  tasking  facility  accepts  these  calls  in  an  arbitrary  manner  (8:9-13)  (15:285). 
Therefore,  arrivals  to  the  entry  queues  are  assumed  to  be  random. 

4.2.2  Service  Distributions.  Regardless  of  the  arrival  pattern,  the  service  time 
of  the  entry  calls  is  random  because  of  the  inherent  randomness  (nondeterministic  nature) 
of  select  statements  within  Ada’s  tasking  facility.  “If  several  alternatives  can  be  selected, 
one  of  them  is  selected  arbitrarily”  (8:9-13). 

The  assumption  of  random  service  is  not  as  crucial  as  the  assumption  of  random 
arrivals.  M/G/l  queues  can  still  be  modeled  using  the  M/M/1  queueing  network  equations 
which  are  used  in  this  research  (17:226). 

4.2.3  General  Distributions.  If  the  Ada  tasking  facility  were  to  be  changed 
in  the  future  so  that  it  incorporated  timing  guarantees,  then  the  following  modifications 
would  be  necessary  to  the  model:  model  general  arrival  times  with  the  G/M/l  queue: 
model  general  service  times  with  the  M/G/l  queue;  and  model  both  general  arrivals  and 
service  times  by  the  G/G/l  queue. 

4.3  Entry  Call  Model 

Figure  4.1  depicts  level  A23  of  the  Ada  Tasking  Model  design.  This  level  has  six 
activities:  Get  Entry  Precedence  Requirements;  Create  Entry  Trace;  Create  Network  of 
Entry  Queues;  Model  Arrival  Patterns;  Solve  Network  Equations',  and  Gather  Performance 
Statistics.  The  following  sections  provide  a  summary  of  the  six  functions.  For  more  details, 
see  Appendix  B. 
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Figure  4.1.  Model  Entry  Calls  -  Level  A23 


4.3.1  Get  Entry  Precedence  Requirements.  Function  A231,  Get  Entry 
Precedence  Requirement ,  has  three  interface  arrows:  a  control  arrow  labeled  task  sched¬ 
ule,  an  input  arrow  labeled  task  info  and  an  output  arrow  labeled  precedences.  The  arrow 
task  schedule  is  a  schedule  of  the  tasks  designed  in  DARTS.  The  task  information  includes 
the  task  names,  periods,  execution  times,  precedences,  etc.  The  arrow  precedences  refers 
to  the  NxN  matrix  of  dependencies  which  is  developed  from  the  precedence  information 
contained  in  task  info. 

The  precedence  requirements  are  input  by  the  designer  in  the  form  of  task  info.  The 
precedences  are  transferred  to  an  NxN  matrix,  where  N  is  the  number  of  entry  points.  The 
matrix  contains  Boolean  values,  with  dependencies  denoted  by  TRUE.  The  function,  Get 
Entry  Precedence  Requirements  reads  in  the  precedence  requirements  and  outputs  an  NxN 
matrix  depicting  those  precedences. 

4.3.2  Create  Entry  Trace.  Function  A232,  Create  Entry  Trace,  has  two  in¬ 
terface  arrows:  a  control  arrow  labeled  precedences ,  which  is  output  from  function  A231 
(Section  4.3.1)  and  an  output  arrow  labeled  entry  trace,  which  is  a  sequence  of  entry  points. 

The  function,  Create  Entry  Trace,  creates  one  possible  sequence  of  entry  calls  based 
upon  the  precedence  matrix.  The  entry  trace  will  be  created  using  a  CSP-like  language: 
the  alphabet  consists  of  the  entry  points.  Another  use  for  the  entry  trace  is  to  show 
whether  or  not  deadlock  occurs  within  the  system.  Section  4.3.6  details  the  uses  of  the 
entry  trace. 

4.3.3  Create  Network  of  Entry  Queues.  Function  A233,  Create  Network 
of  Entry  Queues,  has  three  interface  arrows:  a  control  arrow  labeled  precedences,  which 
originates  from  Function  A231;  an  input  arrow  labeled  task  info,  which  was  described 
in  Section  4.3.1;  and  an  output  arrow  labeled  network,  which  is  the  queueing  network. 
The  queues  represent  the  entry  points,  i.e.,  the  accept  statements.  The  queueing  network 
will  be  modeled  as  a  network  of  M/M/1  queues.  The  connections  between  the  separate 
queues  are  contained  within  an  NxN  matrix  Q.  This  matrix  is  similar  to  the  precedence 
matrix  described  above  except  that  the  entries  are  values  between  0  and  1  which  denote 


P 


6 


the  probability  of  leaving  queue  i  (represented  by  row  i)  and  entering  queue  j  (represented 
by  column  j). 

The  function,  Create  Network  of  Entry  Queues ,  reads  in  the  precedences  matrix 
and  the  task  info  and  produces  a  queueing  network  matrix  depicting  the  interconnections 
between  the  entry  queues. 

4-3.4  Model  Arrival  Patterns.  Function  A234,  Model  Arrival  Patterns,  has 
four  interface  arrows:  a  control  arrow  labeled  network ,  which  originates  from  function 
A233;  an  input  arrow  labeled  task  info ,  which  was  described  in  Section  4.3.1;  an  input 
arrow  labeled  task  schedule ,  which  originates  from  function  A22;  and  an  output  arrow 
labeled  arrivals,  which  describes  the  arrival  distributions  for  each  of  the  queues. 

The  function,  Model  Arrival  Patterns,  assigns  an  arrival  distribution  to  each  of  the 
entry  queues.  As  previously  stated,  this  research  assumes  the  arrival  patterns  can  be 
modeled  using  the  exponential  distribution.  If  future  changes  are  made  to  the  Ada  tasking 
facility  which  nullify  these  assumptions,  then  this  segment  of  the  model  will  need  to  be 
redefined.  However,  as  mentioned  previously,  this  model  is  valid  for  either  M/M/1  or 
M/G/l  queueing  networks. 

4.3.5  Solve  Network  Equations.  Function  A235,  Solve  Network  Equations,  lias 
four  interface  arrows:  a  control  and  input  arrow  labeled  arrivals,  which  originates  liom 
Function  A234;  an  input  arrow  labeled  network,  which  originates  from  Function  A233:  and 
an  output  arrow  labeled  solution,  which  is  a  matrix  of  equations  that  solve  the  queueing 
network.  The  function,  Solve  Network  Equations,  reads  in  the  network  matrix  and  the 
arrival  distributions  and  finds  the  arrival  rates  (A)  and  the  service  rates  (/i). 

Because  the  queues  are  assumed  to  be  M/M/1,  the  network  can  be  modeled  using 
Jackson  network  equations  (16:149-150).  Jackson’s  method  allows  open  or  closed  networks 
and  feedback.  The  individual  queues  are  referred  to  as  “nodes”  and  the  arrivals  as  “cus¬ 
tomers.”  Arrivals  from  outside  the  system  arrive  according  to  the  Poisson  distribution 
(e.g.,  interarrivals  have  exponential  distributions)  at  the  rate  7 i.  Customers  move  from 
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node  j  to  node  »  with  probability  r,',*.  (Note  that  the  probability  of  a  customer  leaving 
node  j  and  feeding  back  to  the  same  node  j  is  r,j.) 

The  total  arrival  rate  of  customers  to  node  i  is  found  by  summing  the  outside  ar¬ 
rivals  and  the  internal  arrivals  which  arrive  from  nodes  within  the  network.  The  following 
equation  represents  the  total  arrival  rate  for  node  ». 

N 

A<  -  7.'  +  £  Ajr ji  fori-  1,2, ..., N  (4.4) 

i=l 

A  network  of  N  nodes  will  have  N  equations  of  this  form. 

4.3.6  Gather  Performance  Statistics.  Function  A236,  Gather  Performance 
Statistics ,  has  three  interface  arrows:  a  control  arrow  labeled  solution ,  which  is  the  output 
from  function  A235;  a  control  arrow  labeled  entry  trace ,  which  is  the  output  from  function 
A232;  and  an  output  arrow  performance  stats ,  which  describes  the  performance  statistics 
generated  by  the  model  developed  within  this  thesis. 

The  function,  Gather  Performance  Statistics ,  gathers  and  calculates  queueing  statis¬ 
tics,  such  as: 

•  arrival  rate  (A) 

•  service  rate  (p) 

•  utilization  of  queues  (p) 

•  time  in  queue  (T) 

•  number  in  queue  ( Nq ) 

•  service  time  (S) 

•  wait  time  ( W ) 

The  statistics  gathered  from  the  queueing  network  are  averages.  See  Appendix  B  for  the 
equations. 

The  entry  trace  generates  a  sequence  of  the  entry  calls.  The  remainder  of  the  infor¬ 
mation  gained  from  the  entry  trace  depends  upon  the  implementation  of  the  trace.  This 
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model  assumes  that  the  trace  will  be  implemented  as  print  statements  within  the  program 
and  that  the  entries  will  be  time  stamped.  Thus,  information  gathered  from  the  entry 
trace,  in  addition  to  the  list  of  entries,  is  the  number  of  times  each  entry  was  called,  when 
the  calls  were  made,  and  general  information  for  the  interarrival  and  service  distributions. 
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V.  Validation 


This  chapter  contains  the  first  attempt  at  validating  the  performance  model  of  Ada 
tasking.  The  validation  compares  the  results  of  applying  the  Ada  Tasking  Model  with 
a  queueing  simulation  and  an  Ada  implementation.  The  Dining  Philosophers  problem 
was  chosen  to  demonstrate  the  validation  because  it  is  a  well-defined  problem  requiring 
concurrent  programming. 

The  life  cycle  for  this  validation,  shown  in  Figure  5.1,  parallels  the  life  cycle  defined 
in  Figure  1.1.  The  numbers  in  Figure  5.1  correspond  to  the  sections  where  each  of  the 
phases  are  developed.  A  general  application  of  the  model  is  contained  in  Section  5..' *  and 
Section  5.6  contains  the  application  for  a  specific  case. 


Figure  5.1.  Validation  Life  Cycle 

5.1  The  Dining  Philosophers 

The  Dining  Philosophers,  first  presented  by  E.W.  Dijkstra  (10:83-99)  (13:75-81),  is 
a  classic  synchronization  problem  which  is  used  to  benchmark  concurrent  programming 
facilities  because  it  illustrates  deadlock  and  starvation  problems  among  shared  resources. 
Hoare  describes  the  Dining  Philosopher  problem  as  follows: 
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In  ancient  times,  a  wealthy  philanthropist  endowed  a  College  to  accommodate 
five  eminent  philosophers.  Each  philosopher  had  a  room  in  which  he  could 
engage  in  his  professional  activity  of  thinking;  there  was  also  a  common  dining 
room,  furnished  with  a  circular  table,  surrounded  by  five  chairs  ...  To  the  left 
of  each  philosopher  there  was  laid  a  golden  fork,  and  in  the  centre  stood  a  large 
bowl  of  spaghetti,  which  was  constantly  replenished.  (13:75) 

In  order  to  eat,  the  philosopher  picks  up  the  forks  closest  to  him,  one  at  a  time.  Once 
the  philosopher  obtains  both  forks,  he  eats  until  he  is  no  longer  hungry,  puts  down  the 
forks,  and  goes  away  to  think  until  he  is  hungry  again  and  then  the  whole  process  repeats. 
Once  a  philosopher  has  possession  of  a  fork,  he  will  not  relinquish  it  until  he  has  finished 
eating,  causing  potential  problems  with  deadlock  and  starvation. 

Deadlock  occurs  when  all  five  philosophers  decide  to  eat  at  the  same  time  and  each 
picks  up  one  fork.  None  of  the  philosophers  will  release  his  fork  until  he  has  eaten,  but 
none  of  the  philosophers  can  eat  until  he  gets  another  fork;  the  philosophers  are  deadlocked. 
Starvation  is  slightly  different  from  deadlock  in  that  one  or  more  of  the  philosophers  obtains 
both  forks  and  eats  while  another  is  never  able  to  pick  up  both  forks  and,  therefore,  starves 
to  death. 

The  Dining  Philosopher  implementation  used  to  validate  the  Ada  Tasking  Model 
employs  a  host  to  ensure  that  deadlock  will  not  occur.  Each  philosopher  must  ask  the  host’s 
permission  to  enter  and  leave  the  dining  room  and  the  host  allows  only  four  philosophers 
in  the  dining  room  at  a  time;  thus,  ensuring  that  at  least  one  of  the  philosophers  will  be 
able  to  eat  at  a  time.  Deadlock  has  been  avoided  (10:88).  Note  that  starvation  may  still 
occur  if  one  of  the  philosophers  sits  at  the  table  and  never  gets  both  forks. 

5.2  Design  Approach  for  Real-Time  Systems  Design 

Figure  5.2  depicts  the  state  flow  for  one  of  the  philosophers  in  the  Dining  Philosophers 
problem.  Once  a  philosopher  enters  the  system  he  continues  to  eat  and  think  until  he  dies. 
The  following  sections  describe  the  DARTS  design  for  the  Dining  Philosophers  problem 
and  describe  the  task  information  required  to  apply  the  tasking  model. 
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5.2.1  DARTS  Design.  Figure  5.3  shows  the  DARTS  diagram  for  one  of  the 
philosophers.  Enter  Dining  Room,  and  Leave  Dining  Room  have  been  placed  in  the  task 
Host.  Pick  Up  Left  Fork ,  Pick  Up  Right  Fork,  Put  Down  Right  Fork,  and  Put  Down 
Left  Fork  have  been  condensed  to  Pick  Up  Fork  and  Put  Down  Fork  in  task  Fork.  The 
Philosopher  task  makes  calls  to  Host  and  Fork.  Note  that  there  are  five  fork  tasks,  five 
philosopher  tasks,  and  one  host  task. 


Figure  5.3.  DARTS  Design  for  Philosopher  i 

Before  eating,  each  philosopher  must  ask  the  host’s  permission  to  enter  the  dining 
room  by  issuing  the  call  Enter.  The  host  will  only  allow  four  philosophers  into  the  dining 
room  at  a  time  so  that  deadlock  will  not  occur. 
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After  entering  the  dining  room,  the  philosopher  sits  in  his  chair  and  tries  to  pick  up 
the  fork  on  his  left  (Fork  t)  and  the  fork  on  his  right  (Fork  *  ®  1).  Table  5.1  shows  the 
left  and  right  fork  numbers  for  each  of  the  philosophers  and  Figure  5.4  shows  the  relative 
positions  of  the  seats  and  the  forks.  (Note,  the  symbol  ©  is  used  to  denote  modulo  5 
addition  (13:75).) 


Table  5, 

L.  Fork  Numbering 

Philosopher 

Left  Fork 

Right  Fork 

0 

0 

1 

1 

1 

2 

2 

2 

3 

3 

3 

4 

4 

4 

0 

Figure  5.4.  Fork  Diagram  for  Dining  Philosophers 
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After  eating,  the  philosopher  puts  down  both  of  his  forks  and  notifies  the  host  that 
he  is  leaving  by  issuing  the  call  Leave.  The  calls  Enter  and  Leave  allow  the  host  task  to 
keep  track  of  the  number  of  philosophers  currently  in  the  dining  room. 

5.2.2  Task  Information.  There  are  eleven  Ada  tasks:  one  Host  task;  five  Fork 
tasks;  and  five  Philosopher  tasks.  The  Host  task  has  two  Ada  entry  points:  enter  and 
leave.  Each  Fork  task  has  two  entries:  pick  up  and  put  down.  The  Philosopher  tasks 
have  no  entries;  each  philosopher  places  calls  to  the  Host  and  Forks.  The  twelve  entries  are 
enumerated  in  Table  5.2.  Philosopher  t  repeats  the  eating-thinking  cycle  with  frequency  /,-. 

The  precedence  requirements  are  defined  by  the  order  in  which  the  entry  calls  can 
be  made.  The  following  list  uses  CSP  notation  to  show  the  order  of  calls  for  Philosopher  i: 


Philosopher {  =  (t .enter — ►  *. pick  up  fork  i — ►  i. pick  up  fork  (i  ©  1) 

— ►  i.put  down  fork  (i  ©  1)  — ►  i.put  down  fork  i  — 
i.leave  — ►  Philosopher ;) 

The  symbol  <•  is  the  precedence  operator  where  i  <•  j  means  that  i.  is  dependent 
upon  j.  Every  entry  point  is  dependent  upon  all  the  other  entry  points  in  steady  state 
because  the  problem  is  circular.  The  precedences  shown  here  are  partial  precedences  that 
only  describe  the  previous  precedence.  The  partial  precedences  for  Philosopher  i  are  shown 
below. 

•  enter  <•  leave 

•  pick  up  fork  i  <•  enter 

•  put  down  fork  i  <  pick  up  fork  i 

•  leave  <•  put  down  forks 

In  addition,  each  of  the  forks  may  have  the  following  precedences,  depending  upon 
which  philosopher  is  eating. 

•  pick  up  fork  1  <■  pick  up  fork  0  (for  Philosopher  0) 
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•  pick  up  fork  2  <■  pick  up  fork  1  (for  Philosopher  1) 

•  pick  up  fork  3  <•  pick  up  fork  2  (for  Philosopher  2) 

•  pick  up  fork  4  <•  pick  up  fork  3  (for  Philosopher  3) 

•  pick  up  fork  0  <•  pick  up  fork  4  (for  Philosopher  4) 

•  put  down  fork  0  <•  put  down  fork  1  (for  Philosopher  0) 

•  put  down  fork  1  <•  put  down  fork  2  (for  Philosopher  1) 

•  put  down  fork  2  <•  put  down  fork  3  (for  Philosopher  2) 

•  put  down  fork  3  <•  put  down  fork  4  (for  Philosopher  3) 

•  put  down  fork  4  <•  put  down  fork  0  (for  Philosopher  4) 

5.3  Application  of  the  Ada  Tasking  Model 

This  section  demonstrates  how  to  apply  the  tasking  model.  The  steps  of  the  model 
are; 

•  Get  Precedence  Requirements; 

•  Create  Entry  Trace; 

•  Create  Network  of  Entry  Queues; 

•  Solve  Network  Equations; 

•  Gather  Performance  Statistics. 

These  steps  are  defined  in  Figure  4.1  in  Chapter  IV.  Notice  that  “Model  Arrival 
Patterns”  was  not  included  because  the  model  assumes  the  arrivals  are  distributed  expo¬ 
nentially. 

5.3.1  Get  Precedence  Requirements.  The  entry  points  and  their  reference 
numbers  are  shown  in  Table  5.2.  These  numbers  will  be  used  as  matrix  indices  throughout 
the  remainder  of  the  application  of  the  model.  Note  that  each  Ada  entry  point  is  modeled 
as  a  separate  queue. 


5-7 


Table  5.2.  Entry  Points 


Entry  # 

Entry  Name 

1 

Enter 

2 

Pick  Up  Fork  0 

3 

Pick  Up  Fork  1 

4 

Pick  Up  Fork  2 

5 

Pick  Up  Fork  3 

6 

Pick  Up  Fork  4 

7 

Put  Down  Fork  0 

8 

Put  Down  Fork  1 

9 

Put  Down  Fork  2 

10 

Put  Down  Fork  3 

11 

Put  Down  Fork  4 

12 

Leave 

The  procedure  Create  Precedence  Matrix  from  Section  B.7.1  in  Appendix  B  was  used 
to  transfer  the  task  information  into  a  NxN  matrix;  N=12  in  this  case  because  there  arc  12 
entry  points.  The  precedence  matrix,  shown  in  Figure  5.5,  contains  Boolean  values,  such 
that  T  =s  True  and  F  =  False.  (The  False  entries  have  been  omitted  from  the  figure  in 
order  to  make  it  more  readable.)  The  “T"  in  the  matrix  represents  a  precedence  between 
the  column  and  the  row,  i.e.,  i  <  j 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

1 

T 

T 

T 

T 

T 

T 

T 

T 

T 

T 

T 

2 

T 

T~ 

T 

3 

hr 

hr 

T 

4 

T 

T 

T 

5 

T 

T 

T 

6 

T 

T“ 

T 

7 

T 

T 

8 

T 

T 

9 

T 

T 

10 

T 

T 

11 

T 

T 

12 

"f" 

Figure  5.5.  Precedence  Matrix 
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5.3.2  Entry  Trace.  This  section  is  based  upon  the  Dining  Philosophers  example 
in  Hoare’s  text  (13:75-81).  There  are  three  basic  tasks  in  the  implementation  of  the  dining 
philosophers:  host,  philosophers,  and  forks;  thus,  there  are  three  alphabets  which  are 
shown  below  with  their  respective  behaviors. 

5.S.2.1  Philosophers.  Each  Philosopher  may  enter  or  leave  the  dining 
room  and  pick  up  or  put  down  forks.  The  alphabet  for  the  philosophers  is: 


a  Philosopher  —  {(.enter,  (.leave,  i.pick  up  fork.i,  i.pick  up  fork.(i  ©  1), 
i.put  down  fork.i, i.put  down  fork.(i  ©  1)} 

A  sample  of  Philosopher  i’s  behavior  is  shown  below. 


Philosopher  =  (i. enter  — ►  i.pick  up  fork.i  — ►  i.pick  up  fork.(i  ©  1)  — 
i.put  down  fork.(i  ©  1)  — ♦  i.put  down  fork.i 
— >  i.leave  — ♦  Philosopher ,) 

5. 3. 2.2  Forks.  Each  Fork  can  be  picked  up  or  put  down.  The  alphabet  for 
the  forks  is: 


a  Fork,  =  {i.pick  up  fork. t',(i©  1). pick  up  fork.i, 

i.put  down  fork.i,{iQ  1  ).put  down  fork.i} 


The  fork’s  behavior  is: 


Fork%  =  ( i.pick  up  fork.i  — ►  i.put  down  fork.i  — ►  Forki  \ 

(i  ©  l).ptcfc  up  fork.i  — ►  (i  0  1  ).put  down  fork.i  — ►  Forki) 

5. 3.2.3  Host.  The  host  allows  the  philosophers  to  enter  or  leave  the  dining 
room.  The  alphabet  for  the  host  is: 

a  Host  ss  \jf-0{i. enter,  i.leave} 
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The  host  only  allows  philosophers  to  enter  if  the  dining  room  is  empty  because  there  are 
no  philosophers  to  leave. 

Hosto  =  ( i.enter  — ►  Host\) 

The  Host  will  allow  the  philosophers  to  enter  or  leave  when  there  are  1  to  3  philosophers 
in  the  dining  room. 

Host,-  as  (i.enter  — ►  Hosty+i  |  i.leave  — ►  Host,_i)  for  j  6  {1,2,3} 

When  four  philosophers  are  in  the  dining  room,  the  host  will  only  allow  philosophers  to 
leave  since  four  is  the  maximum  number  allowed  in  order  to  prevent  deadlock. 

Host4  as  (i.leave  — ►  Hosts) 

5.3.24  Concurrency.  The  components  work  together  concurrently  and 
are  described  as  follows: 

Philosophers  =  (Philoaophero\\Philosopheri\\PhUosopher2\\Philosopher3\\Ph  ilo.wiilir  r  4 
Forks  as  (ForfcollForfciHFor^llForfcsIlFor^) 

Dining  Philosophers  =  (Philosophers  ||  Forks  ||  Host) 

5. 3. 2. 5  Trace.  A  CSP-like  trace  can  be  created  either  manually  or  via 
automation.  The  trace  for  this  implementation  was  created  by  embedding  commands  in 
the  Ada  program.  Both  the  Ada  code  and  entry  trace  are  located  in  Appendix  C.,  A 
portion  of  the  trace  is  shown  in  Figure  5.6. 

5.3.3  Create  Network  of  Entry  Queues.  The  next  step  in  applying  the  Ada 
Tasking  Model  is  to  create  the  entry  queue  network.  The  queueing  network  may  be  drawn 
manually  if  the  number  of  queues  is  small;  otherwise,  an  NxN  matrix  is  created,  where  the 
indices  represent  the  entry  queue  numbers.  Figure  5.7  shows  the  queueing  network  for  the 
entry  queues.  Although  this  network  only  has  sixteen  queues,  it  is  still  unwieldy  to  draw; 
therefore,  matrices  are  used  for  this  model  because  they  are  much  easier  to  manipulate 
and  store  on  a  computer. 
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Philosopher  0  enters  dining  room  — ►  Philosopher  0  picks  up  fork  0  — ♦ 
Philosopher  0  picks  up  fork  1  — *•  Philosopher  1  enters  dining  room  — * 
Philosopher  2  enters  dining  room  — ►  Philosopher  3  enters  dining  room  — * 
Philosopher  2  picks  up  fork  2  — ►  Philosopher  3  picks  up  fork  3  — ► 
Philosopher  3  picks  up  fork  4  — ►  Philosopher  0  puts  down  fork  1  — ► 
Philosopher  1  picks  up  fork  1  — ►  Philosopher  0  puts  down  fork  0  — ► 
Philosopher  0  leaves  dining  room  — ►  Philosopher  4  enters  dining  room  — ► 
Philosopher  3  puts  down  fork  4  — ►  Philosopher  4  picks  up  fork  4  — ► 
Philosopher  3  puts  down  fork  3  — ►  Philosopher  2  picks  up  fork  3  — ► 
Philosopher  4  picks  up  fork  5  — ►  Philosopher  3  leaves  dining  room  — ► 
Philosopher  2  puts  down  fork  3  — ►  Philosopher  4  puts  down  fork  5  — ► 
Philosopher  2  puts  down  fork  2  — ►  Philosopher  1  picks  up  fork  2  — + 
Philosopher  4  puts  down  fork  4  — ►  Philosopher  2  leaves  dining  room  — * 
Philosopher  4  leaves  dining  room  — ►  ■ . . _  _ 

Figure  5.6.  Entry  Trace  for  Dining  Philosophers 


The  Tji  matrix,  shown  in  Figure  5.8,  represents  the  probabilities  of  transitioning 
between  queues,  e.g.,  Tji  is  the  probability  of  moving  from  queue  j  to  queue  i.  If  equals 
zero,  then  the  transition  between  the  queues  cannot  occur.  The  queue  interconnections 
are  determined  from  the  precedence  matrix  in  Figure  5.5  and  the  rJt-  values  are  calculated 
in  Section  5.3.4. 

Note  that  the  matrix  has  been  expanded  from  12x12  to  16x16  matrix.  The  Leave 
queue  will  be  used  to  model  the  thinking  time  for  the  philosophers;  therefore,  the  Leave 
queue  was  expanded  from  one  to  five  queues.  This  was  done  so  that  the  queueing  model 
could  allow  the  philosophers  to  have  their  own  “think”  queue;  thus,  allowing  the  possibility 
for  independent  thinking  rates. 
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5.3.4  Solve  Network  Equations.  This  section  calculates  the  rji  probabilities 
for  the  general  case;  Section  5.6  solves  the  equations  for  a  specific  case.  In  order  for  the 
queueing  network  to  be  in  steady  state,  no  deaths  will  occur;  therefore,  the  probability  of 
leaving  queues  12-16  and  entering  queue  1  is  equal  to  1. 

t*12,l  =  **13,1  =  **14,1  =  ris,!  =  1*16,1  =  1 

Note  that  this  network  is  a  closed  system  with  five  customers  and  that  the  external 
arrivals  (7,)  are  0  because  the  system  is  closed.  The  system  has  sixteen  queues;  therefore, 
there  are  sixteen  simultaneous  equations  to  solve  of  the  form: 

N 

Xi  =7 i  +  5Z  r3*‘ \>  f°r  *  =  2»  -» 16  (5- 1 ) 

j=l 

Because  the  7,’s  are  zero,  this  set  of  equations  does  not  have  a  unique  solution.  However. 
At  is  equal  to  the  sum  of  all  the  philosopher’s  arrival  rates  and  can  be  substituted  into  the 
following  set  of  equations  to  gain  a  unique  solution. 

Ai  =  r12,1^12  +  t*l3,lAi3  +  ri4,iAi4  +  ris.iAis  +  ri6,lAi6 

A2  =  71,2^1  +  **6,2^6 
A3  ~  ^1,3^1  +  t*2t3^2 

A4  =  ri,4Ai  +  r3i4A3 

A5  =  **1,5^1  +  f4,5^4 

Ae  =  fx.sAi  4-  7*5, 6A5 
A7  =  **2,7^2  +  **8,7  As 
X$  =  r3,aA3  4-  TgfiXg 
A9  —  r4,9^4  4-  rio.gAio 

X10  —  7*5,10^5  4-  ^11,10^11 
All  =  **6,11^6  +  f7,llA7 
A12  =  ^7,12^7 

Al3  =  >*8,13^8 

A14  = 

Al5  =  flO.lsAlO 
Aie  -  fii.ieAn 
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5.3.5  Calculating  the  fjj’s.  The  r,-,-’s  denote  probabilities  of  transitioning  be¬ 
tween  queue  j  and  i  and  the  sum  of  the  probabilities  leaving  a  queue  is  1.  Note  that  each 
of  the  rows  of  the  r,-,-  matrix  in  Figure  5.8  denotes  the  probability  of  leaving  a  specific 
queue,  hence,  the  fj<’s  in  each  row  must  sum  to  1.  Thus,  the  following  equations  may  be 
obtained  from  the  r#  matrix. 


»*i,2  +  1*1,3  4-  ri,4  4*  ri,s  +  ri,e  =  1 

probability  of  leaving  queue 

»*2,3  +  **2,7  =  1 

probability  of  leaving  queue 

**3,4  +  **3,8  =  1 

probability  of  leaving  queue 

**4,5  +  **4,9  =  1 

probability  of  leaving  queue 

**5,6  +  **5,10  =  1 

probability  of  leaving  queue 

**6,2  +  **6,11  =  1 

probability  of  leaving  queue 

**7,11  +  **7,12  =  1 

probability  of  leaving  queue 

**8,7  +  **8,13  =  1 

probability  of  leaving  queue 

**9,8  +  1*9,14  =  1 

probability  of  leaving  queue 

1*10,9  +  1*10,15  =  1 

probability  of  leaving  queue 

1*11,10  4- 1*11,16  =  1 

probability  of  leaving  queue 

Each  of  the  philosophers  completes  an  eating-thinking  cycle  with  frequency  Thus, 
the  arrival  rate  at  queue  1  (Aj)  is  equal  to  the  sum  of  these  frequencies,  i.e.,  X\  =  £;=o  /«• 
The  relationship  between  the  frequencies  is  arbitrary,  so  assume  that  the  frequency  at 
which  the  philosophers  eat  is  related  by  the  following  equation: 


/o  =  —  =  —  =  —  =  —  (5.2) 

X\  *2  X4  v 

where  the  x,’s  are  arbitrary  constants.  This  relationship  allows  a  general  solution  to  be 
developed  for  each  of  the  rj,-  probabilities. 

5.3.5. 1  Probabilities  of  Leaving  Queue  1.  The  following  equation  rep¬ 
resents  the  sum  for  all  the  probabilities  of  leaving  queue  1. 


1*1,2  +  1*1,3  +  1*1,4  +  1*1,5  +  1*1,6  =  1 


(5.3) 
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Iu  order  to  solve  for  the  fjj’s,  it  is  necessary  to  understand  that  each  of  these  rj,’s  represent 
the  probability  of  a  philosopher  selecting  his  left  fork.  For  example,  rli2  represents  the 
probability  that  Philosopher  0  leaves  queue  1  and  picks  up  Fork  0. 

Each  of  these  probabilities  are  mutually  exclusive  and  depend  upon  the  rate  at  which 
the  philosophers  complete  their  eating-thinking  cycle.  The  probability  that  Philosopher  0 
leaves  queue  1  is  equal  to  his  eating-thinking  frequency  (/i)  divided  by  the  sum  of  all 
the  eating-thinking  frequencies  (Ai).  Therefore,  Philosopher  0  leaves  queue  1  with  the 
probability  of: 


So  _  /o  _ _ fo _ 

£<=o  Si  fo  +  /i  +  S%  +  So  +  /<i 


This  fraction  can  be  simplified  by  exploiting  the  relationship  between  the  eating- 
thinking  frequencies. 

fn-h.-S2.-h.-h. 

X\  X2  X3  Xi 

Thus, 


/l  =  *i/o 
=  *2/0 


/3  -  *3/0 


Sa  =  *4/0 


Substituting  these  values  into  Eq  5.4  yields  the  following  equation: 

_  __  fo  _  _ fa _  _  _ 1 _ 

ti2  ( /o +*1  /o  +xj  /o  +X3  /o  fo )  /o  ( 1  +si  +  *2  +*3  +x«  )  l+xi+xj+Xi+m 

Likewise,  the  probabilities  that  Philosophers  1-4  leave  queue  1  and  pick  up  their  left  forks 
are: 


fi,3  = 


f  1 ,4  = 


_ 

1+XJ+X2+X3+X4 

Xi _ 

1+X1+X2+I3+I4 


Th  5  = 


*3 _ 

1+X1+X2+X3+X4 


rl,6“ 


I+XI+X2+X3+X4 
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5.S.5.2  Probabilities  of  Leaving  Queue  2.  Queue  2  represents  the  entry 
Pick  Up  Fork  0  and  is  called  by  either  Philosopher  0  or  Philosopher  4.  Philosopher  0  leaves 
queue  2  and  enters  queue  3  with  frequency  /o.  Philosopher  4  leaves  queue  2  and  enters 
queue  7  with  frequency  f\.  Therefore, 


5. 3.5.3  Probabilities  of  Leaving  Queues  3-6.  The  queues  3-6  also 
represent  picking  up  a  fork  and  the  probabilities  are  derived  similarly  to  those  above. 
Therefore, 

^  =  7o+7T  =  ilk  r3-»  *  7S+7T  =  rfe 

r“-5  =  7lfe  =  ~  7i+7i  =  51+^ 

rs,6  =  ]£r3  =  ^  rs,io  =  7^7 j  ^ 

r6-2  “  7S+7T  "  r6-n  =  lA Ti  =  A+Ta 

5. 3.5. 4  Probabilities  of  Leaving  Queues  7-11.  Queues  7-11  represent 
putting  down  forks.  The  following  equations  represent  the  probabilities  of  leaving  these 
queues. 

r742  =  jAt<  =  T+S7  r7,u  =  75+77  =  r?£7 
r8.i3  =  75+7^  =  ifir  r8-7  =  7o+7T  =  rfer 
r9,i4  =  7T+7*  =  il+i?  =  7T+7*  =  ^ 

fio.is  -  /2+y3  — ■  x2+®3  7io,9  —  75+73  —  12+13 

rn,i6  =  ^$77  =  j^7  ru.io  =  7^77  =  55^7 
5../  SLAM  II  Simulation 

Now  that  the  rJt-  probabilities  have  been  calculated,  it  is  possible  to  create  a  queueing 
model  simulation  in  SLAM  II  (Simulation  Language  for  Alternative  Modeling)  which  is 
a  FORTRAN-based  simulation  language  (20).  The  SLAM  II  model  has  sixteen  queues, 
where  each  queue  represents  one  Ada  entry  point.  (See  Table  5.2.)  One  important  differ¬ 
ence  between  SLAM  II  and  general  queueing  theory  is  that  SLAM  II  uses  times,  whereas, 
queueing  theory  uses  rates.  However,  the  rate  is  simply  the  inverse  of  the  time  period. 
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The  realistic  service  time  for  picking  up  and  putting  down  forks  can  be  approximated 
by  zero.  The  time  of  interest  for  the  forks  is  not  the  service  time,  but  rather  the  wait  time 
when  the  fork  is  in  use  by  another  philosopher.  Thus,  instead  of  modeling  the  service  times 
as  zero,  the  time  will  be  used  as  part  of  the  delay  due  to  eating. 

There  are  four  steps  necessary  for  the  eating  process: 

•  pick  up  left  fork; 

•  pick  up  right  fork; 

•  put  down  right  fork:  and 

•  put  down  left  fork. 

The  eating  service  time  will  be  divided  between  the  pick  up  left  fork  and  pick  up 
right  fork  queues,  such  that  the  sum  of  the  service  times  equals  the  total  time  spent  eating. 
This  allows  a  more  realistic  representation  where  the  philosophers  may  be  requited  to  wait 
to  pick  up  their  forks.  The  queues  for  putting  down  the  forks  will  have  zero  service  times 
because  the  philosophers  do  not  have  to  wait  in  line  to  put  down  the  forks. 

The  queue  where  the  philosopher  notifies  the  host  that  he  is  leaving  the  dining  room 
is  used  to  model  the  thinking  time.  Each  philosopher  has  his  own  thinking  queue  so  that 
it  is  possible  for  all  the  philosophers  to  think  concurrently  and  at  differing  rates. 

The  code  and  simulation  output  are  contained  in  Appendix  C.  The  statistics  from 
the  SLAM  II  simulations  are  contained  within  Section  5.6.  The  next  section  describes  the 
Ada  program  for  the  Dining  Philosophers. 

5.5  Ada  Implementation 

The  Ada  implementation  contains  an  array  of  five  fork  tasks,  an  array  of  five  philoso¬ 
pher  tasks,  one  host  task,  and  two  tasks  used  to  collect  statistics  while  the  Ada  program  is 
executing.  The  collection  tasks  are  used  because  I/O  on  a  VERDIX  system  is  a  subprocess 
of  the  task  and  will  suspend  the  task,  thus,  distorting  the  runtime  statistics.  The  Ada  code 
and  entry  trace  are  located  in  Appendix  C.  The  statistics  gathered  from  the  Ada  program 
and  from  the  SLAM  II  simulation  are  located  in  the  next  section. 
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5.6  Dining  Philosopher  Solution 

5.6. 1  Solve  Network  Equations.  The  philosopher  eating  frequencies  are  related 
by  the  following  equation: 

/o  =  —  =  —  =  —  =  —  (5.5) 

Xt  Xj  X3  X4 

where  the  x,’s  are  arbitrary  scaling  constants.  The  sum  of  all  the  frequencies  is  equal  to 
the  arrival  rate  at  Queue  1  in  the  queueing  network: 

•*1  =  £  ft  (5.6) 

is  0 

The  solution  presented  here  assumes  that  all  the  philosophers  think  at  different  rates,  such 
that, 

xi  =  2 

x2  =  3 
X3  =  4 
X\  ss  5 

Each  philosopher  eats  for  approximately  1  hour.  Let  Philosopher  0  think  for  9  hours 
and  eat  for  1  hour;  therefore,  his  eating-thinking  cycle  takes  approximately  10  hours  and 
repeats  with  frequency  /o  =  ^5.  Plugging  this  value  and  the  above  x;  values  into  Eq  5.5 
yields  the  following  results.  (The  hour  time  unit  is  actually  modeled  as  seconds.) 

/o  =  To 

h  =  1 

/*  =  £ 

/3  =  § 

/4  =  * 

and 

^1  =  fo  +  fi  +  h  +  h  +  h  =  | 
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The  tji  probabilities  shown  below  were  calculated  using  MACSYMA.  The  batch  file  is 
contained  in  Appendix  C. 

rU  =  TE 
ri.3  =  & 

*1,4  =  £ 
ri.s  =  Is 

**1,6  =  **3,8  =  **8,7  =  3 
r3,4  =  **8,13  =  § 

**2,3  =  **7,12  =  g 
**2,7  =  **7,11  =  | 

**4,5  =  rg.n  =  f 
*•4,9  =  **9,8  =  f 
75,6  =  **10,15  =  | 

*•5,10  =  **10,9  =  § 

**6,2  =  **11,16  =  | 
r6,ll  =  **11,10  =  § 

**12,1  =  **13,1  =  **14,1  =  **15,1  =  **16,1  =  1 

The  sixteen  simultaneous  equations  shown  below  are  solved  by  substituting  in  the 
Tji  values  and  A*. 

■^1  =  **12,lAi2  +  **13,1^13  +  **14,1  A14  +  **l5,lAl5  +  **16,iA16 

A2  =  ri  ,2  Ai  +  re^Ag 
A3  =  **1,3Ai  +  **2,3^2 
A4  =  ri^Aj  +  **3,4^3 
A5  =  **l,5Ai  +  **4,5^4 
^6  =  **i,6Ai  +  **5,6As 
A7  =  **2^2  +  78i7A8 
As  =  **3^3  +  r9|8A9 

A9  =  **4,gA4  +  **10,9Aio 

^10  =  **5,loA5  +  **11,10^11 

^11  =  **6,llAe  +  77,1^7 
Al2  =  7742A7 

^13  =  **8,13^8 
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Al4  =  >*9,14^9 
AlS  =  ^10,15^10 

Al6  =  **11,  16^11 


The  resulting  A  values  are: 


Aj-Ar-f 
A3  =  As  =  ^ 
A4  =  A9  =  ^ 
As  =  Aio  =  ^ 
As  =  An  —  yq 

Al2=  ^ 

Al3  =  5 

Ah  =  fjj 

Ai5  =  § 

Al6  =  2 


5.6.2  Gather  Performance  Statistics.  The  statistics  of  interest  for  the  Dining 
Philosophers  are  the  arrival  rate  (A),  service  rate  (p),  queue  utilization  (p),  and  service  time 
(S').  Note  that  the  simulated  values  are  often  less  than  the  theoretical  values  because  the 
equations  used  to  calculate  the  theoretical  values  are  based  upon  the  assumption  that  there 
is  an  infinite  population  when,  in  fact,  there  are  only  five  entities  circulating  throughout 
the  queueing  network.  The  theoretical  A’s,  p’s,  p’s,  and  S’s  are  shown  in  Table  5.3. 

The  utilization  factor,  p,  is  the  “fraction  of  time  that  a  server  is  busy”  (16:19),  i.e., 
the  “ratio  of  the  rate  at  which  ‘work’  enters  the  system  to  the  maximum  rate  (capacity) 
at  which  the  system  can  perform  this  work”  (16:18).  Symbolically, 


Table  5.3.  Expected  Queueing  Statistics 


Queue 

■a 

P 

P 

_Al 

1 

KE3 

2.000 

0.75 

EH 

2 

0.6 

1.000 

0.60 

1.0 

3 

ESI 

1.000 

0.30 

1.0 

4 

ESI 

1.000 

0.50 

1.0 

5 

EB 

1.000 

0.70 

KHI 

6 

0.9 

1.000 

0.90 

LOl 

7 

E23 

— 

— 

EH 

8 

— 

— 

iilil 

9 

m 

— 

— 

0.0 

10 

fill 

— 

— 

ESI 

11 

0.9 

— 

— 

iilil 

12 

0.1 

0.111 

0.90 

ESI 

13 

0.2 

0.250 

0.80 

4.0 

14 

0.3 

0.429 

0.70 

2.3 

15 

0.4 

0.667 

0.60 

1.5 

16 

0.5 

1.000 

0.50 

1.0 

where  m  is  the  number  of  available  servers,  A  is  the  queue  arrival  rate,  and  ft  is  the  queue 
service  rate.  All  the  queues  are  single  server  queues;  therefore,  m  =  1.  Queues  7-11,  put 
clown  forks,  have  zero  service  times  and  will  not  be  included  in  this  statistical  analysis. 
Table  5.4  shows  the  simulated  and  theoretical  utilization  factors  for  the  queues. 

The  service  rates  for  the  queues  are  used  to  approximate  the  eating  and  thinking 
times.  Each  eat  cycle  has  four  steps  (pick  up  left  fork,  pick  up  right  fork,  put  down  right 
fork,  and  put  down  left  fork)  and  the  pick  up  left  and  right  fork  queues  are  used  to  model 
the  eating  time.  Each  pick  up  fork  queue  will  have  a  service  time  equal  to  the  eating  time 
in  order  to  simulate  the  wait  time  for  a  philosopher  if  the  fork  is  in  use.  In  the  worst  case, 
a  philosopher  will  have  to  wait  for  both  forks. 

There  are  five  thinking  queues  in  order  to  allow  the  five  philosophers  to  think  con¬ 
currently.  Tables  5.5  and  5.6  contain  the  average  eating  and  thinking  service  times  for  the 
SLAM  II  simulations  and  the  Ada  implementation.  Table  5.7  contains  the  eating-thinking 
cycle  times. 
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Table  5.7.  Average  Eating-Thinking  Cycle 


Expected 

SLAM  II 

% 

Ada 

% 

PhilO 

Value 

10.0 

Average 

10.190 

error 

1.86 

Average 

10.566 

Error 

5.36 

Phil  1 

5.0 

5.128 

2.50 

5.447 

8.21 

Phil  2 

3.3 

3.375 

1.24 

3.460 

1CE1 

Phil  3 

2.5 

2.574 

2.87 

2.615 

4.40 

Phil  4 

waam 

2.103 

4.90 

1.942 

2.90 

5. 7  Discussion  of  Results 

This  section  presents  an  overview  of  the  results  gained  from  applying  the  Ada  Tasking 
Model,  SLAM  II  model,  and  the  Ada  implementation. 

The  simulated  queue  utilization  values  did  not  match  the  expected  values  because 
there  were  only  5  entities  circulating  within  the  network.  Finite  population  queueing 
networks  are  “self-regulating,”  meaning  that  “when  the  system  gets  busy,  with  many  of 
these  customers  in  the  queue,  then  the  rate  at  which  additional  customers  arrive  is  in  fact 
reduced,  thus  lowering  the  further  congestion  of  the  system”  (16:106).  Thus,  the  utilization 
was  much  lower  than  expected. 

The  service  times  are  independent  of  the  number  circulating  within  the  network; 
thus,  the  values  for  these  statistics  are  accurate  to  within  10%. 

In  addition,  the  entry  trace  demonstrated  that  the  addition  of  the  Host,  to  the  Din¬ 
ing  Philosophers  Problem  does,  in  fact,  prevent  deadlock.  Thus,  it  was  shown  that  the 
DARTS  design  is  effective  in  preventing  deadlock  without  requiring  that  the  actual  code 
be  implemented. 

This  chapter  has  shown  how  to  apply  the  Ada  Tasking  Model.  As  already  men¬ 
tioned,  the  simulated  results  are  often  less  than  the  theoretical  results  because  the  theory 
is  based  upon  an  infinite  population.  It  is  not  possible  to  exactly  model  an  Ada  program 
in  SLAM  II;  however,  the  results  from  the  simulation  may  be  used  to  build  confidence  in 
the  theoretical  values  derived  for  the  queueing  network. 
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Although  this  validation  does  not  formally  prove  that  the  Ada  Tasking  Model  is 
correct,  it  does  demonstrate  that  formally  modeling  Ada  tasking  is  feasible.  In  order  for 
this  model  to  be  useful,  it  must  be  automated.  The  automation  will  make  the  application 
of  the  model  much  easier  and  allow  changes  to  be  made  without  causing  the  entire  process 
to  be  repeated.  A  discussion  on  improving  the  Ada  Tasking  Model  is  presented  in  the  next 
chapter. 


VI.  Conclusions  and  Recommendations 


6.1  Motivation  for  Research 

As  software  system  requirements  become  more  complex,  software  engineers  must 
carefully  design  their  systems  to  ensure  that  the  systems  adequately  meet  all  the  re¬ 
quirements,  both  functional  and  non-functional.  Because  real-time  systems  have  timing 
constraints,  in  addition  to  the  more  traditional  behavioral  constraints,  a  comprehensive 
software  design  analysis  model  is  required  which  incorporates  performance,  timing,  and 
behavioral  constraints.  Although  the  Ada  language  tasking  constructs  are  compiler  inde¬ 
pendent,  Ada  tasking  is  dependent  on  its  runtime  environment;  therefore,  a  formal  model 
of  Ada  tasking  is  important  in  order  for  system  designers  to  make  realistic  decisions  when 
modeling  Mission  Critical  Computer  Resources  (MCCR)  systems. 


6.2  Conclusions 

•  Feasibility. 

The  main  focus  of  this  research  effort  was  to  determine  the  feasibility  of  developing 
a  parameterized,  formal  model  of  Ada  tasking.  This  research  showed  that  such  a 
parameterized  model  could  be  developed  by  creating  a  mathematical  model  which 
incorporated  real-time  scheduling  and  queueing  theory. 

•  Exponential  Distribution  Assumption. 

The  model  is  based  upon  the  assumption  that  arrival  and  service  times  are  expo¬ 
nential  for  entry  queues.  This  assumption  allowed  Ada  entry  points  to  be  modeled 
as  M/M/1  queues.  The  model  needs  to  be  broadened  to  include  general  arrival  and 
service  distributions. 

•  Modularity. 

The  model  was  built  modularly  so  that  changes,  such  as  to  the  distributions,  could 
be  easily  incorporated.  Another  purpose  behind  the  modularity  was  to  allow  the 
model  to  be  parameterized  so  that  the  model  could  be  tailored  for  specific  software 
applications  and  runtime  environments. 


•  Usability. 

The  Ada  Tasking  Model  needs  to  be  automated  in  order  to  be  usable.  The  automa¬ 
tion  would  also  allow  changes  to  be  made  easily. 

•  Design  Analysis  Environment. 

The  model  can  be  used  in  the  future  to  develop  a  design  analysis  environment  for 
real-time  software  systems  that  require  Ada  as  the  target  language.  Thus,  given 
a  specification  for  such  a  system,  the  design  analysis  environment  can  be  used  to 
obtain  the  information  needed  to  support  Ada  software  design  decisions. 

6.3  Recommendations 

•  General  Distributions. 

The  Ada  Tasking  Model  assumes  that  arrival  and  service  times  are  exponential  for 
entry  queues;  thus,  allowing  each  Ada  entry  point  to  be  modeled  as  an  M/M/1 
queue.  If  the  Ada  tasking  facility  were  modified  so  that  it  included  timing  guarantees, 
then  the  model  would  need  to  consider  general  arrival  and  service  distributions. 
The  queues  would  be  modeled  as  G/M/l  for  general  arrival  distributions,  M/G/l 
for  general  service  distributions,  and  G/G/l  for  both  general  arrival  and  service 
distributions.  Function  A234,  Model  Arrival  Patterns ,  will  need  to  be  redesigned  in 
tin  event  that  arrival  distributions  can  be  other  than  exponential. 

•  Automation. 

Additionally,  the  model  should  ultimately  be  automated  to  facilitate  its  application. 
The  software  engineer  should  only  need  to  input  the  task  information  to  the  Ada 
Tasking  Model  which  would  then  manipulate  the  information  and  produce  the  entry 
trace  and  performance  statistics. 

•  SADT. 

This  research  used  SADT  to  model  the  Ada  tasking  model.  The  SUN  work  stations  at 
AFIT  contain  a  CASE  tool  called  SAtool  which  automate  the  application  of  SADT. 


6-2 


This  tool  should  be  used  in  the  future  because  of  its  automated  data  dictionary  and 
consistency  checking. 

•  Further  Research. 

Model  Design  Performance  is  divided  into  two  functions:  Define  Task  Performance 
Requirements  (Function  Al);  and  Ada  Tasking  Model  (Function  A2).  (See  Fig¬ 
ure  3.2.)  This  research  effort  concentrated  on  developing  the  Ada  Tasking  Model. 
Future  research  should  develop  Define  Task  Performance  Requirements  and  its  input 
control  non-functional  requirements. 
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Appendix  A.  Glossary  of  Acronyms 

AFIT  Air  Force  Institute  of  Technology 

ATM  Ada  Tasking  Model 

CPU  Central  Processor  Unit 

CSP  Communicating  Sequential  Processes 

DARTS  Design  Approach  for  Real-Time  Systems 

DoD  Department  of  Defense 

ECS  Embedded  Computer  System 

FCFS  First-Come-First-Serve 

IOP  Input/Output  Processor 

LRM  Language  Reference  Manual 

MCCR  Mission  Critical  Computer  Resources 

pdf  Probability  Density  Function 

PDF  Probability  Distribution  Function 

RTE  Runtime  Environment 

RR  Round  Robin 

RSTA  Real-Time  Structured  Analysis 

SADT  Structured  Analysis  and  Design  Technique 

SJF  Shortest-Job-First 


UNITY  Unbounded  Nondeterministic  Iterative  Transformations 


Appendix  B.  Detailed  Design 


B.l  Environment  Model 

Figure  B.l  represents  the  environmental  model. 


Software 
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Figure  B.l.  Environment  Model 


B.2  Model  Design  Performance 

Figure  B.2  represents  the  AO  level  of  the  model.  This  level  is  decomposed  further  to 
levels  Al,  Define  Task  Performance  Requirements ,  and  A2,  Ada  Tasking  Model. 

B.3  Define  Task  Performance  Requirements 

Level  Al,  labeled  Define  Task  Performance  Requirements ,  will  be  designed  in  a  later 
research  effort. 
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Figure  B.2.  Level  AO 
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D.4  Ada  Tasking  Model 

Level  A2,  labeled  Ada  Tasking  Model,  models  the  performance  of  a  given  Ada  design. 
Function  A2  (shown  in  Figure  B.3)  returns  a  Boolean  flag,  labeled  schedulable;  a  task 
schedule;  an  entry  trace;  and  performance  statistics,  based  upon  the  information  included 
in  task  info  and  RTE. 


Figure  B.3.  Level  A2 

Level  A2  is  further  decomposed  to  three  functions:  level  A21,  Determine  Unschedu- 
lability,  level  A22,  Create  Schedule ;  and  level  A23,  Model  Entry  Calls.  These  functions  are 
described  in  detail  in  the  following  sections. 
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D.5  Determine  Unschedulability 


The  steps  to  determine  unschedulability  are:  Determine  Pairwise  Task  Compatibility; 
Find  Maximal  Compatible  Sets  of  Tasks;  and  Determine  Lower  Bound  on  Number  of 
Processors.  (See  Figure  B.4.) 


tuk  info 


Figure  B.4.  Determine  Unschedulability 


B.5.1  Determine  Pairwise  Task  Compatibility.  Create  an  NxN  incompati¬ 
bility  matrix  where  N  is  the  number  of  tasks  to  be  scheduled.  As  previously  mentioned, 
two  tasks  are  incompatible  if  they  cannot  be  scheduled  together  on  a  single  processor.  The 
incompatibility  occurs  if  the  sum  of  their  load  factors  is  greater  than  1  or  if  the  sum  of  their 
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execution  times  is  larger  than  the  greatest  common  divisor  of  their  periods  (21:55).  The 
following  pseudocode  describes  the  algorithm  to  create  the  incompatibility  matrix  (21:70). 


procadura  Craata.Incompatibility.M&trix  it 
i, j  «  indices  of  loop  counters 
N  *  number  of  tasks 
T  *  array  (1..N)  of  task  periods 

E  ■  array  (i..N)  of  task  execution  times 

M  *  array  (1..K,  1..N)  of  Boolean 
—  M  is  the  incompatibility  matrix 
—  True  means  incompatible 

—  False  means  not  incompatible,  i.e.  compatible 
gcd  is  a  separate  function  which  returns  the  greatest  common 
divisor  of  two  integers 

begin  procedure 

for  i  in  1..N  loop 
for  j  in  1..N  loop 
if  i*j  then 

M(i,i)  *  False  —  every  task  is  compatible 
—  with  itself 

else 

if  Ei  +  Ej  <»  gcd  (Ti,  Tj)  then 

—  task  i  k  j  are  compatible 
M(i,j)  «  False 

else 

—  task  i  t  j  are  incompatible 
M(i,j)  ■  True 

end  if 
end  if 
end  loop 
end  loop 
end  procedure 


B.5.2  Find  Maximal  Compatible  Sets  of  Tasks.  The  functions,  Zeroj,  Zerol, 
list,  push,  and  pop,  used  within  the  algorithm,  are  defined  first  before  describing  the 
algorithm  itself.  The  call  Zeroj  (j,  M)  takes  the  matrix  M  and  zeros  out  all  the  entries  in 
the  jth  column  and  the  jth  row  (21:77).  The  call  Zerol  (j',  M)  takes  the  matrix  M  and 
zeros  all  the  rows  that  have  l’s  in  the  jth  column  and  then  zeros  out  the  entries  in  the  jth 
row  and  column  (21:77).  Function  list(j)  returns  the  list  of  tasks  represented  by  a  1  in  row 
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j.  The  other  functions,  push  and  pop,  refer  to  stack  operations.  Pushing  an  item  places 
it  on  the  top  of  the  stack  and  popping  removes  an  item  from  the  top  of  the  stack.  The 
algorithm  has  three  stacks:  job  stack,  job  complement  stack,  and  array  stack. 

The  following  algorithm  uses  the  incompatibility  matrix  created  in  the  previous  step 
to  produce  a  list  of  maximal  compatible  sets  which  are  sets  of  tasks  which  do  not  exclude 
each  other  from  being  scheduled  on  the  same  processor.  Seward’s  Algorithm  2.1  (21:81-82) 
was  found  to  be  too  general;  the  problems  with  this  algorithm  are: 

1.  It  assumes  that  the  tree  will  always  have  a  left  and  right  leaf.  This  is  not  true  because 
most  of  the  left  branches  branch  out  further,  leaving  only  a  right  leaf.  The  algorithm 
always  tries  to  get  the  maximal  compatible  list  from  the  left  leaf  even  when  it  does 
not  exist. 

2.  Sometimes  a  right  branch  branches  down  another  level,  but  the  algorithm  never 
considers  this  possibility.  When  this  occurs,  it  is  necessary  to  pop  an  extra  array  and 
job  list  from  their  stacks  in  order  to  back  up  to  the  next  node  in  the  tree. 

The  modified  algorithm  is  shown  below. 

Step  1.  Find  the  maximum  number  of  ones  in  any  column. 

This  task  will  become  the  root  of  the  tree. 

decision:  if  none  of  the  columns  contain  any 
1*3,  then  move  on  to  Step  3,  skipping  Step  2. 

Step  2.  push  job  (column  number)  onto  job  stack 

push  list  (j)  onto  job  complement  stack 

push  Zeroj  ( j ,  M)  onto  array  stack 

set  incompatibility  array  R  »  Zeroj  ( j ,  M) 

Goto  Step  4. 

Step  3.  R  now  has  only  zeroes, 
handle  the  left  leaf 
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(the  tree  will  only  have  loft  loavos  on 
tho  first  time  through  the  algorithm  and  if  a 
right  branch  branches  down  a  whole  level.) 

—  get  maximal  compatible  (MC)  list  and  store  it 

backup  to  node  and  go  down  right  side 
~  pop  job  stack  twice 

—  push  job  complement  list  onto  job  stack 

handle  the  right  leaf 

—  get  maximal  compatible  (MC)  list  and  store  it 

backup  2  nodes 

—  pop  job  stack  twice 

if  the  right  branch  was  down  a  whole 
level  (having  two  leaves)  then  have 
to  pop  an  extra  job  list  and  array 
from  the  stacks) 

—  pop  job  stack 

—  pop  array  stack 

prepare  to  go  down  right  branch 
--  pop  job  complement  stack 

—  push  job  complement  onto  job  stack 

—  pop  array  stack  twice 

if  back  at  the  root  then  stop, 
else  R  *  Zerol  (last  array  popped) 

Step  4.  (An  extension  of  step  1.) 

Find  the  maximum  number  of  ones  in  any  column. 

decision:  if  there  are  zeros  in  the  matrix 
and  this  is  not  the  first  time  through  (depth 
first  search)  then  the  tree  is  branching  into 
an  extra  level. 

goto  Step  2. 
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B.5.S  Determine  Bound  on  Number  of  Processors.  An  estimate  of  the 
lower  bound  can  be  found  by  summing  the  load  factors  and  taking  the  ceiling  of  the  sum. 
In  other  words,  the  minimum  number  of  processors  is  equal  to 

KEfn  (b.i) 

This  lower  bound  offers  the  least  number  of  processors  that  is  possible.  An  approach  which 
consistently  produces  a  more  realistic  lower  bound  is  described  below. 

Determining  the  minimal  number  of  processors  is  part  of  the  Set  Covering  Problem 
(21:207).  Finding  the  minimal  covering,  however,  is  not  enough  because  each  of  the  job 
sets  must  be  load  consistent  if  they  are  to  be  scheduled  on  a  single  processor.  A  load 
consistent  set  is  a  set  of  tasks  whose  load  factors  sum  is  less  than  unity.  Therefore,  the 
minimal  covering  only  gives  a  lower  bound  for  the  minimum  number  of  processors  required. 

Because  a  valid  schedule  must  have  load  consistent  sets,  every  minimal  covering  must 
be  found  and  every  irredundant  cover  that  is  not  minimal  must  also  be  found  (21:211-212). 
Seward  defines  an  irredundant  covering  as  a  covering  in  which  the  removal  of  one  of  the 
maximal  compatible  (MC)  sets  causes  the  set  to  no  longer  be  a  cover  (21:211-212). 

The  following  is  an  algorithm  for  finding  the  lower  bound  of  processors  required. 

Step  1:  create  a  cover  table  where  the  rows  represent  the 
MC  lists  and  the  columns  represent  the  jobs. 

Place  a  1  in  the  table  to  represent  that  a  job  is 
present  in  the  MC  list. 

Step  2:  if  a  column  contains  a  single  1,  then  the  corresponding 
MC  list  is  an  essential  MC  because  the  job  is  only 
contained  in  that  MC  list.  This  MC  must  be  contained 
in  all  the  solutions. 

Remove  the  MC  from  the  cover  table  and  all  the  jobs 
which  are  contained  in  the  MC  list. 

Step  3:  Check  the  table  for  equivalent  rows  and  remove  them. 


Step  4: 


Repeat  Steps  2  k  3  until  no  more  essential  MC  lists 


are  found. 


Step  5:  Find  the  list  of  maximal  compatible  sets  for  the 

jobs  which  axe  not  contained  in  the  essential  MC  lists. 

Step  6:  Append  the  essential  NCs  to  the  new  MC  lists.  The 

number  of  lints  gives  the  lower  bound  on  the  required 
number  of  processors. 

B.6  Create  Schedule 

Function  A22,  Create  Schedule ,  creates  a  schedule  of  the  tasks  based  upon  the  task 
scheduler  for  the  RTE.  This  model  does  not  worry  about  finding  the  optimum  schedule 
because  this  is  often  an  NP-complete  problem  (21).  For  example,  the  seemingly  simple  case 
of  finding  the  optimum  solution  for  a  system  with  a  nonpreemptive  scheduling  algorithm, 
independent  tasks,  and  unequal  execution  times  is  an  NP-complete  problem  (21:12). 

B.7  Model  Entry  Calls 

Figure  B.5  depicts  level  A23  of  the  model  design.  This  level  has  six  functions:  Get 
Entry  Precedence  Requirements;  Create  Entry  Trace;  Create  Network  of  Entry  Queues; 
Model  Arrival  Patterns;  Solve  Network  Equations ;  and  Gather  Performance  Statistics. 
The  following  sections  describe  each  of  these  functions. 

B.7.1  Get  Entry  Precedence  Requirements.  The  precedence  information  is 
received  from  the  designer  who  inputs  the  task  information.  This  information  is  transferred 
to  an  NxN  matrix,  where  N  is  the  number  of  entry  points.  The  matrix  contains  Boolean 
values  with  dependencies  denoted  by  TRUE.  The  column  depends  upon  the  row.  If  entry  j 
depends  upon  entry  i,  then  M(iJ)  =  TRUE;  M(i,i)  =  FALSE  because  a  task  cannot  depend 
upon  itself. 

The  following  pseudocode  describes  the  algorithm  to  create  the  precedence  matrix. 
The  function  is.precedence(i,j)  checks  the  task  information  to  see  whether  or  not  the  entry 
j  depends  upon  the  entry  t. 
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Figure  B.5.  Model  Entry  Calls  -  Level  A23 


procedure  Create.Precedence.Matrix  is 
i, j  =  indices  of  loop  counters 
N  *  number  of  entry  points 

T  ■  array  (1..N)  of  entry  precedence  constraints 

M  *  array  (1..M,  1..N)  of  Boolean 

—  M  is  the  precedence  matrix 
—  True  means  precedence  constraint,  i.e. ,  dependent 
--  False  means  no  constraint,  i.e.,  independent 
is.precedence(j ,i)  is  a  separate  function  which  returns  TRUE 
if  j  is  constrained  by  i. 

begin  procedure 

for  i  in  1..N  loop 
for  j  in  1..N  loop 
if  i=j  then 

M(i,i)  ■  False  —  an  entry  does  not  depend 
—  upon  itself 

else 

if  is.precedence(TCj) ,  T(i))  then 
—  task  j  depends  upon  i 
M(i,j)  *  True 
else 

~  task  i  *  j  are  independent 
M(i, j)  *  False 
end  if 
end  if 
end  loop 
end  loop 
end  procedure 


B.7.2  Create  Entry  Trace.  The  entry  trace  will  be  created  using  a  CSP— like 
language.  The  entry  points  are  modeled  as  members  of  the  alphabet.  Hoare  suggests  that 
CSP  can  be  represented  by  a  LISP  program  (13:47).  The  validation  model  in  this  thesis 
incorporates  the  entry  calls  into  an  Ada  program. 

The  entry  points  are  modeled  as  members  of  an  alphabet.  Each  task,  or  possibly 
subsystem,  can  have  its  own  alphabet.  If  two  tasks  run  concurrently  and  if  an  event  is  in 
both  of  the  alphabets,  then  the  event  must  occur  simultaneously.  If  the  event  is  in  only 
one  of  the  alphabets,  then  it  may  occur  independently  (13:68-69).  The  same  interaction 
is  true  for  “N”  concurrent  tasks. 
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CSP  ignores  timing  details,  but,  if  the  entry  trace  is  automated,  then  the  addition 
of  a  time  stamp  can  easily  be  added.  These  times  will  be  useful  for  giving  general  timing 
relationships  between  different  entry  calls. 

B.7.3  Create  Network  of  Entry  Queues.  The  queues  represent  the  entry 
points,  i.e.,  the  accept  statements.  The  arrival  rate  is  determined  by  the  calling  task(s) 
and  the  queues  will  be  represented  by  M/M/1  queues.  The  interconnections  between  the 
entry  queues  are  determined  by  the  precedence  matrix  developed  in  Section  B.7.1. 

This  segment  of  the  model  may  b  ascribed  by  manually  drawing  the  queueing 
network  if  the  number  of  queues  is  small.  Otherwise,  an  NxN  probability  matrix  is  created, 
where  the  indices  of  the  matrix  represent  entry  queues.  This  matrix  is  similar  to  the 
precedence  matrix  described  above  except  that  the  entries  are  values  between  Or  1 
which  denote  the  probability  of  leaving  queue  i  (represented  by  row  i)  and  er.'.ering  q.  •■e 
j  (represented  by  column  j). 

This  matrix  is  referred  to  as  the  matrix  of  transition  probabilities  (P)  for  discrete 
systems  and  as  the  matrix  of  transition  rates  (Q)  for  continuous  systems  (17:53).  This 
model  will  use  the  Q  matrix  because  it  assumes  exponential  distributions  which  imply 
that  the  system  is  continuous. 

B.7.4  Model  Arrival  Patterns.  The  arrival  distributions  for  the  model  de¬ 
veloped  in  this  thesis  are  assumed  to  be  Poisson;  therefore,  the  ir.terarrival  process  is 
exponential.  (The  notation  used  in  this  section  is  consistent  with  that  used  by  Kleir.rock 
(16)). 

The  Poisson  distribution  is  shown  in  the  following  equation. 

Pk(t)  =  fork>0,t>0  (B.2) 

A  is  the  average  rate  at  which  customers  arrive  at  the  queue.  The  average  time 
between  arrivals  is  1/A.  Pk(t)  is  the  probability  of  k  ar  r,,als  during  the  time  interval  (0,t). 
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The  time  between  arrivals  is  exponentially  distributed;  therefore,  the  interarrival  times  are 
exponential. 

The  exponential  Probability  Distribution  Function  (PDF)  (16:65)  for  arrivals  is  de¬ 
noted  as: 


A(t)  =  1  -  e~Xt  fort>  0  (B.3) 

And  the  exponential  Probability  Density  Function  (pdf)  (16:65)  is: 

a(t)  —  ^  =  Xe~xt  for  t>  0  (B.4) 

at 

The  arrival  rate  (A)  for  each  of  the  queues  is  placed  in  a  row  vector,  where  the  index 
refers  to  the  queue  number  from  Section  B.7.1. 

5.7.5  Solve  Network  Equations.  Because  the  queues  are  assumed  to  !>o 
M/M/1,  the  network  can  be  modeled  using  the  Jackson  network  equation  below  (16:149- 
150), 

N 

=  7 i  +  Vii  f°r  *  =  1,2,  ...,iV  (B.5) 

}- 1 

where  the  s  are  the  rates  described  in  the  Q  matrix  in  Section  B.7.3  and  the  A’s  are  the 
arri*  .  rates  described  in  Section  B.7.4. 

There  is  an  equation  for  each  queue.  The  set  of  equations  may  be  solved  by  hand  or 
simultam  ously  by  placing  them  in  a  matrix  and  using  a  mathematical  software  program. 
Figure  B.6  shows  one  queue  out  of  the  system  of  queues. 

External  arrivals  (7;)  are  arrivals  from  outside  the  network  which  have  the  Poisson 
distribution.  Internal  arrivals  A *»•*;  arrive  from  other  queues  within  the  network.  Feedback 
is  represented  by  A,r;,.  External  departures  leave  the  system  entirely  and  are  represented 
as  A;(l  -  Y,j  rij)-  Internal  departures  leave  Queue  t  as  A ,r,j  and  are  internal  arrivals  at 
Queue  j. 
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Figure  B.6.  Queue  i  in  Network 

B.7.6  Gather  Performance  Statistics.  The  entry  trace  generates  a  sequence  of 
the  entry  calls.  The  remainder  of  the  information  gained  from  the  entry  trace  depends  upon 
the  implementation  of  the  trace.  This  model  assumes  that  the  trace  will  be  implemented 
as  output  statements  within  the  program  and  that  the  events  will  be  time  stamped.  Thus, 
information  gathered  from  the  entry  trace,  in  addition  to  the  list  of  events,  is  the  number 
of  times  each  entry  was  called,  when  the  calls  were  made,  and  general  information  for  the 
interarrival  and  service  distributions. 

The  statistics  gathered  from  the  queueing  network  are  averages.  The  information 
may  include: 

•  arrival  rate  (A) 

•  service  rate  (/i) 

•  utilization  of  queues  ( p ) 

•  time  in  queue  ( T ) 

•  number  in  queue  (Nq) 

•  service  time  (S(y)) 
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•  wait  time  ( W(y )) 


The  values  of  A  and  p  are  calculated  in  the  function  Solve  Network  Equations.  The 
equations  for  the  remaining  variables  are  shown  below: 


II 

a- 

tT 

(B.6) 

T  _  i/m 

(B.T) 

1  -P 

N  =  AT  =  -r— 

1  -p 

(B.8) 

S(y)  —  1  -  e~^1~p^y  for  y  >  0 

(B.9) 

W(y)  =  1  -  pe~^1~p'>y  for  y>  0 

(B.10) 
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B.8  Data  Dictionary 


B.8.1  List  of  Activities 

A-0  MODEL  DESIGN  PERFORMANCE 

A1  DEFINE  TASK  PERFORMANCE  REQUIREMENTS 

A2  Ada  TASKING  MODEL 

A21  DETERMINE  PAIRWISE  TASK  COMPATIBILITY 

A22  CREATE  SCHEDULE 

A23  MODEL  ENTRY  CALLS 

A231  GET  ENTRY  PRECEDENCE  REQUIREMENTS 

A232  CREATE  ENTRY  TRACE 

A233  CREATE  NETWORK  OF  ENTRY  QUEUES 

A234  MODEL  ARRIVAL  PATTERNS 

A235  SOLVE  NETWORK  EQUATIONS 

A236  GATHER  PERFORMANCE  STATISTICS 


I 

NAME:  Ada  TASKING  MODEL 
TYPE:  ACTIVITY 
PROJECT:  ATM 
NUMBER:  A2 
DESCRIPTION: 

The  Ada  tasking  model  models  the  performance  of  the  Ada 
design  which  was  developed  by  a  method  such  as  DARTS. 
The  model  returns  a  task  schedule,  and  event  trace,  and 
performance  statistics. 

INPUTS:  none 
OUTPUTS:  SCHEDULABLE 
TASK  SCHEDULE 
ENTRY  TRACE 
PERFORMANCE  STATISTICS 
CONTROLS:  TASK  INFO 
MECHANISMS:  RTE 

PARENT  ACTIVITY:  MODEL  DESIGN  PERFORMANCE 
REFERENCE:  Appendix  B 
I 

NAME:  CREATE  ENTRY  TRACE 
TYPE:  ACTIVITY 
PROJECT:  ATM 
NUMBER:  A232 
DESCRIPTION: 

This  function  creates  an  event  trace  which  is  a  linear 
list  of  the  entry  calls. 

INPUTS:  none 
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OUTPUTS:  ENTRY  TRACE 
CONTROLS:  PRECEDENCES 
MECHANISMS:  non* 

PARENT  ACTIVITY:  MODEL  ENTRY  CALLS 
REFERENCE:  Appendix  B 
I 

NAME:  CREATE  NETWORK  OF  ENTRY  QUEUES 

TYPE:  ACTIVITY 

PROJECT:  ATM 

NUMBER:  A233 

DESCRIPTION: 

Th*  network  of  entry  queues  is  developed  from  the  entries 
which  are  input  from  the  software  design. 

INPUTS:  TASK  INFO 
OUTPUTS:  NETWORK 
CONTROLS:  PRECEDENCES 
MECHANISMS:  none 

PARENT  ACTIVITY:  MODEL  ENTRY  CALLS 
REFERENCE:  Appendix  B 
I 

NAME:  CREATE  SCHEDULE 
TYPE:  ACTIVITY 
PROJECT:  ATM 
NUMBER:  A22 
DESCRIPTION: 

Create  schedule  creates  a  schedule  based  upon  the  task 
information,  task  scheduler,  and  number  of  processors 
available. 

INPUTS: 

NUM  PROCESSORS 
TASK  INFO 

OUTPUTS:  TASK  SCHEDULE 
CONTROLS:  SCHEDULABLE 
MECHANISMS:  SCHEDULER  INFO 
PARENT  ACTIVITY:  Ada  TASKING  MODEL 
REFERENCE:  Appendix  B 
I 

NAME:  DEFINE  TASK  PERFORMANCE  REQUIREMENTS 

TYPE:  ACTIVITY 

PROJECT:  ATM 

NUMBER:  A1 

DESCRIPTION: 

Defining  the  task  performance  requirements  will  be 
designed  in  a  follow-on  thesis. 

INPUTS:  NON-FUNCTIONAL  REQUIREMENTS 
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OUTPUTS:  TASK  INFO 
CONTROLS:  SOFTWARE  DESIGN 
MECHANISMS:  none 

PARENT  ACTIVITY:  MODEL  DESIGN  PERFORMANCE 
REFERENCE:  Appendix  B 

I 

NAME:  DETERMINE  BOUND  ON  NUMBER  OF  PROCESSORS 

TYPE:  ACTIVITY 

PROJECT:  ATM 

NUMBER:  A213 

DESCRIPTION: 

This  function  estimates  the  upper  and  lower  bounds  of  the 
required  number  of  processors  for  the  given  set  of  tasks. 
INPUTS: 

TASK  INFO 

NUM  PROCESSORS 

OUTPUTS: 

BOUNDS 

SCHEDULABLE 

CONTROLS:  MAXIMAL  COMPATIBLE  LIST 
MECHANISMS:  none 

PARENT  ACTIVITY:  DETERMINE  UNSCHEDULABILITY 
REFERENCE:  Appendix  B 
I 

NAME:  DETERMINE  PAIRWISE  TASK  COMPATIBILITY 

TYPE:  ACTIVITY 

PROJECT:  ATM 

NUMBER:  A211 

DESCRIPTION: 

This  function  compares  every  pair  of  tasks  to  see  if  they 
can  co-exist  on  the  same  processor.  An  incompatibility 
occurs  if  the  sum  of  their  load  factors  is  greater  than 
unity  or  if  the  sum  of  their  execution  times  is  larger 
than  the  greatest  common  divisor  of  their  periods. 

INPUTS:  none 

OUTPUTS:  INCOMPATIBILITY  MATRIX 
CONTROLS:  TASK  INFO 
MECHANISMS:  none 

PARENT  ACTIVITY:  DETERMINE  UNSCHEDULABILITY 
REFERENCE:  Appendix  B 
I 

NAME:  DETERMINE  UNSCHEDULABILITY 
TYPE:  ACTIVITY 
PROJECT:  ATM 
NUMBER:  A21 


B-18 


DESCRIPTION: 

Determine  unschedulability  is  a  necessary  condition  for 
determining  if  a  set  of  tasks  can  be  scheduled. 

INPUTS:  NUM  PROCESSORS 
OUTPUTS: 

BOUNDS 
SCHEDULABLE 
CONTROLS:  TASK  INFO 
MECHANISMS:  none 

PARENT  ACTIVITY:  Ada  TASKING  MODEL 
REFERENCE:  Appendix  B 
I 

NAME:  FIND  MAXIMAL  COMPATIBLE  SETS 

TYPE:  ACTIVITY 

PROJECT:  ATM 

NUMBER:  A212 

DESCRIPTION: 

This  function  uses  the  incompatibility  matrix  to  produce 
a  list  of  maximal  compatible  sets  which  are  sets  ox  tasks 
which  do  not  exclude  each  other  from  being  scheduled  on 
the  same  processor. 

INPUTS:  TASK  INFO 
OUTPUTS:  MAXIMAL  COMPATIBLE  LIST 
CONTROLS:  INCOMPATIBILITY  MATRIX 
MECHANISMS:  none 

PARENT  ACTIVITY:  DETERMINE  UNSCHEDULABILITY 
REFERENCE:  Appendix  B 

I 

NAME:  GATHER  PERFORMANCE  STATISTICS 

TYPE:  ACTIVITY 

PROJECT:  ATM 

NUMBER:  A236 

DESCRIPTION: 

This  function  generates  statistics  based  upon  the  entry 
trace  and  the  queueing  network  of  entries. 

INPUTS:  none 

OUTPUTS:  PERFORMANCE  STATISTICS 
CONTROLS: 

SOLUTION 
ENTRY  TRACE 
MECHANISMS:  none 

PARENT  ACTIVITY:  MODEL  ENTRY  CALLS 
REFERENCE:  Appendix  B 
I 

NAME:  GET  ENTRY  PRECEDENCE  REQUIREMENTS 
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TYPE:  ACTIVITY 
PROJECT:  ATM 
NUMBER:  A231 
DESCRIPTION: 

Th*  precedence  requirements  art  input  by  the  designer  and 
this  function  converts  than  into  a  format  acceptable  for 
the  Ada  Tasking  Modal. 

INPUTS:  TASK  INFO 
OUTPUTS:  PRECEDENCES 
CONTROLS:  SCHEDULABLE 
MECHANISMS:  none 

PARENT  ACTIVITY:  MODEL  ENTRY  CALLS  (A23) 

REFERENCE:  Appendix  B 

I 

NAME:  MODEL  ARRIVAL  PATTERNS 

TYPE:  ACTIVITY 

PROJECT:  ATM 

NUMBER:  A234 

DESCRIPTION: 

This  function  dascribas  the  arrival  distributions  for 
each  of  the  entry  queues  in  the  network  developed  in 
A233. 

INPUTS: 

TASK  INFO 
TASK  SCHEDULE 
OUTPUTS:  ARRIVALS 
CONTROLS:  NETWORK 
MECHANISMS:  none 

PARENT  ACTIVITY:  MODEL  ENTRY  CALLS  (A23) 

REFERENCE:  Appendix  B 

I 

NAME:  MODEL  DESIGN  PERFORMANCE 

TYPE:  ACTIVITY 

PROJECT:  ATM 

NUMBER:  A-0 

DESCRIPTION: 

Modeling  design  performance  is  accomplished  after  the 
initial  design  has  been  accomplished  by  a  method  such  as 
DARTS. 

INPUTS:  NON-FUNCTIONAL  REQUIREMENTS 
OUTPUTS:  PERFORMANCE  STATISTICS 
CONTROLS:  SOFTWARE  DESIGN 
MECHANISMS:  RTE 
PARENT  ACTIVITY:  none 
REFERENCE:  Appendix  B 


B-20 


NAME:  MODEL  ENTRY  CALLS 
TYPE:  ACTIVITY 
PROJECT:  ATM 
NUMBER:  A23 
DESCRIPTION: 

Modal  entry  calls  models  the  entries  in  the  Ada  design 
and  returns  an  entry  trace  and  performance  statistics. 
INPUTS:  TASK  INFO 
OUTPUTS: 

ENTRY  TRACE 
PERFORMANCE  STATISTICS 
CONTROLS:  TASK  SCHEDULE 
MECHANISMS:  none 

PARENT  ACTIVITY:  Ada  TASKING  MODEL 
REFERENCE:  Appendix  B 
I 

NAME:  SOLVE  NETWORK  EQUATIONS 

TYPE:  ACTIVITY 

PROJECT:  ATM 

NUMBER:  A23S 

DESCRIPTION: 

This  function  solves  the  network  of  equations  based  upon 
the  arrival  distributions. 

INPUTS:  NETWORK 
OUTPUTS:  SOLUTION 
CONTROLS:  ARRIVALS 
MECHANISMS:  none 

PARENT  ACTIVITY:  MODEL  ENTRY  CALLS 
REFERENCE:  Appendix  B 


B.8.2  List  of  Data  Elements 


ARRIVALS 

BOUNDS 

ENTRY  TRACE 

INCOMPATIBILITY  MATRIX 

MAXIMAL  COMPATIBLE  LIST 

NETWORK 

NON-FUNCTIONAL  REQUIREMENTS 
NUM  PROCESSORS 
PERFORMANCE  DATA 
PERFORMANCE  STATISTICS 
PRECEDENCES 
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RTE 

SCHEDULABLE 
SCHEDULER  INFO 
SOFTWARE  DESIGN 
SOLUTION 
TASK  INFO 
TASK  SCHEDULE 


I 

NAME:  ARRIVALS 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

ARRIVALS  describes  the  inter arrival  distributions  for 
each  of  the  entry  queues  in  the  network  developed  in 
A233.  The  interarrivals  are  assumed  to  follow  the 
exponential  distribution. 

DATA  TYPE:  exponential  distribution 

SOURCES:  A234 

DESTINATIONS 

INPUT:  none 

CONTROL:  A235 

REFERENCE:  Appendix  B 

I 

NAME:  BOUNDS 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

Bounds  is  an  integer  range  which  represents  the  upper  and 
lower  bounds  for  the  number  of  processors. 

DATA  TYPE:  INTEGER 
MIN  VALUE:  1 
SOURCES:  A21,  A213 
DESTINATIONS: 

INPUT:  none 
CONTROL :  none 
REFERENCE:  Appendix  B 
I 

NAME:  ENTRY  TRACE 
TYPE:  DATA  ELEMENT 
PROJECT;  ATM 
DESCRIPTION: 

The  entry  trace  is  a  linear  list  of  the  entry  calls. 
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DATA  TYPE:  list 

PART  OF:  PERFORMANCE  DATA 

SOURCES:  A2,  A23,  A232 

DESTINATIONS: 

INPUT:  non* 

CONTROL:  A236 
REFERENCE:  Appendix  B 
I 

NAME:  INCOMPATIBILITY  MATRIX 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

The  incompatibility  matrix  is  an  NxN  matrix  representing 
which  tasks  cannot  ba  scheduled  on  the  same  processor. 
DATA  TYPE:  NxN  matrix  of  Boolean 
SOURCES:  A211 
DESTINATIONS: 

INPUT:  none 
CONTROL:  A212 
REFERENCE:  Appendix  B 
I 

NAME:  MAXIMAL  COMPATIBLE  LIST 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

A  maximal  compatible  set  is  a  set  of  tasks  which  do  not 
exclude  each  other  from  being  scheduled  on  the  same 
processor.  This  element  is  a  list  of  all  such  sets. 

DATA  TYPE:  list 
SOURCES:  A212 
DESTINATIONS: 

INPUT :  none 
CONTROL:  A213 
REFERENCE:  Appendix  B 
I 

NAME:  NETWORK 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

Network  describes  the  queueing  network  developed  to 
represent  each  of  the  entries. 

DATA  TYPE:  NxN  matrix 
MIN  VALUE:  0 
MAX  VALUE:  1 
SOURCES:  A233 
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DESTINATIONS: 

INPUT:  A23S 
CONTROL:  A234 
REFERENCE:  Appendix  B 
I 

NAME:  NON-FUNCTIONAL  REQUIREMENTS 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

System  constraints  expressed  in  natural  language. 

DATA  TYPE:  Natural  language 
SOURCES:  environment 
DESTINATIONS: 

INPUT:  A-O,  A1 
CONTROL:  none 
REFERENCE:  Appendix  B 
I 

NAME:  NUM  PROCESSORS 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

The  number  of  processors  that  are  available  in  the  system 
which  is  being  modeled. 

DATA  TYPE:  INTEGER 
MIN  VALUE:  1 
PART  OF:  RTE 
SOURCES:  environment 
DESTINATIONS: 

INPUT:  A21,  A22,  A213 
CONTROL :  none 
REFERENCE:  Appendix  B 
I 

NAME:  PERFORMANCE  DATA 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

Performance  criteria  is  the  output  of  the  model  and 
consists  of  a  task  schedule,  event  trace,  and  performance 
statistics. 

COMPOSITION: 

SCHEDULABLE 
TASK  SCHEDULE 
ENTRY  TRACE 
PERFORMANCE  STATISTICS 
SOURCES:  A-0 
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DESTINATIONS: 

INPUT:  non* 

CONTROL:  non* 

REFERENCE:  Appondix  B 

I 

NAME:  PERFORMANCE  STATISTICS 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

Th*  performance  statistic*  are  generated  from  the  event 
trace  and  th*  queueing  network.  Th*  statistics  include 
wait  time,  service  time,  queue  size,  queue  utilization, 
and  arrival  time. 

DATA  TYPE:  positive,  real  numbers 
PART  OF:  PERFORMANCE  DATA 
SOURCES:  A2,  A23,  A236 
DESTINATIONS: 

INPUT:  none 
CONTROL :  none 
REFERENCE:  Appendix  B 
I 

NAME:  PRECEDENCES 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

Precedences  is  an  NxN  matrix  which  describes  if  one  task 
is  dependent  upon  another  task  in  order  to  execute. 

DATA  TYPE:  NxN  matrix  of  Boolean 

SOURCES:  A231 

DESTINATIONS: 

INPUT:  none 
CONTROL:  A233,  A232 
REFERENCE:  Appendix  B 
I 

NAME:  RTE 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

The  RTE  (runtime  environment)  consists  of  the  computer 
hardware  and  the  operating  system.  The  data  element 
contains  the  number  of  available  processors  and  the 
scheduling  information. 

COMPOSITION: 

NUM  PROCESSORS 
SCHEDULER  INFO 
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SOURCES :  environment 
DESTINATIONS: 

INPUT:  none 
CONTROL :  none 
MECHANISM:  A-O,  A2 
REFERENCE:  Appendix  B 
I 

NAME:  SCHEDULABLE 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

A  Boolean  flag  designating  whether  the  given  tasks  can 
be  scheduled  within  the  constraints  of  the  task 
information  and  RTE. 

DATA  TYPE:  BOOLEAN 
VALUES: 

FALSE  *  tasks  cannot  be  scheduled 

TRUE  *  tasks  may  or  may  not  be  schedulable,  move 

onto  the  next  step 
PART  OF:  PERFORMANCE  DATA 
SOURCES:  A2,  A21,  A213 
DESTINATIONS: 

INPUT:  none 
CONTROL:  A213 
REFERENCE:  Appendix  B 
I 

NAME:  SCHEDULER  INFO 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

The  scheduler  information  describes  the  type  of  task 
scheduler  and  entry  scheduler.  The  entry  scheduler  is 
assumed  to  be  a  nonpreemptive  FCFS  scheduler. 

PART  OF:  RTE 
SOURCES:  none 
DESTINATIONS: 

INPUT:  none 
CONTROL:  none 

MECHANISH:  A22 
REFERENCE:  Appendix  B 
I 

NAME:  SOFTWARE  DESIGN 
TYPE:  DATA  ELEMENT 

PROJECT:  ATM 
DESCRIPTION: 
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The  software  design  is  developed  prior  to  invoking  the 
performance  model,  possibly  using  a  method  such  as  DARTS. 
DATA  TYPE:  Natural  language 
SOURCES :  environment 

DESTINATIONS: 

INPUT:  none 
CONTROL:  A-0,  A1 
REFERENCE:  Appendix  B 
I 

NAME:  SOLUTION 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

Solution  represents  the  solution  to  the  set  of 
simultaneous  equations  from  the  queueing  network. 

DATA  TYPE:  matrix  of  equations 

SOURCES:  A235 

DESTINATIONS: 

INPUT:  none 
CONTROL:  A236 
REFERENCE:  Appendix  B 
I 

NAME:  TASK  INFO 
TYPE:  DATA  ELEMENT 
PROJECT:  ATM 
DESCRIPTION: 

The  task  information  is  input  by  the  designer  and 
includes  the  task  name  or  id,  period  or  frequency, 
execution  time,  precedence  requirements,  and  entry 
points . 

DATA  TYPE:  record 
COMPOSITION: 

TASK.ID 

FREQUENCY 

EXECUTION.TIME 

PRECEDENCES 

ENTRY. INFO 

SOURCES:  A1 

DESTINATIONS: 

INPUT:  A212,  A213,  A22,  A23,  A231,  A233,  A234 
CONTROL:  A2,  A21,  A211 
REFERENCE:  Appendix  B 
I 

NAME:  TASK  SCHEDULE 
TYPE:  DATA  ELEMENT 
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PROJECT:  ATM 
DESCRIPTION: 

Th«  task  schedule  is  a  schsduls  based  upon  the  given  task 
information  and  RTE.  The  schedule  may  or  may  not  be 
optimal. 

PART  OF:  PERFORMANCE  DATA 
SOURCES:  A2 
DESTINATIONS: 

INPUT:  A234 
CONTROL:  A23 
REFERENCE:  Appendix  B 
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Appendix  C.  Validation  Programs 


C.l  Dining  Philosophers  Solution 

C.1.1  MACSYMA  Batch  File.  The  rji  probabilities  and  As  were  calculated  in  MAC- 
SYMA.  The  augmented  coefficient  A  matrix  derived  in  MACSYMA  is  shown  below. 
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The  MACSYMA  batch  file  is  shown  below. 


x: matrix (  [1]  ,  [2]  ,  [3]  ,  [4]  ,  [S] ) ; 

10:  1/10; 
f 1 :  x[2]  *  10; 

12:  x[3]  *  10; 

13:  x[4]  *  10; 

14:  x[5]  *  10; 

11:  10  +  11  +  12  +  13  +  14; 

x_sum:  x[i3  +  x[2]  +  x[3]  +  x[4]  +  x[5] ; 

rl21:  1; 

rl31:  1; 

rl41:  1; 

rl51:  1; 

rl61:  1; 

rl2:  x[l]/x_sua; 

rl3:  x[2]/x_su»; 

rl4:  x[3]/x_sum; 

rl5:  x[4]/x_sum; 

rl6:  x[5]/x_sum; 

r23:  x[l]/(x[l]  +  x[S3); 
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r27:  xC5]/(xCl]  +  x[S]); 
r34:  xC2]/(xCl]  +  x[2]); 
r38:  xCl]/(xCl]  +  xC2]); 
r45:  x[3]/(x[2]  +  x[3]); 

r49:  x[2]/(x[2]  +  xC3]); 

tS8:  xC4]/(x[3]  +  x[4]); 

rSlO:  x[3]/(x[3]  ♦  xC4]); 
r«2:  x[6]/(x[4]  +  x[S]); 

rail:  xC4]/Cx[4]  +  x[5])j 
r711:  xC5]/(xCl]  +  xC5]); 
r712:  x[l]/(x[l]  +  xC6]); 
r87;  xCl]/(xEl]  +  xC2]); 
r813:  xC2]/(xCl]  +  x[2]); 
r98:  x[2]/(xC2]  +  x[3]); 

r914:  x[3]/(x[2]  +  x[3]); 
rl09:  xC3]/(x[3]  +  xC4]); 
rl015:  xC4]/(x[3]  +  x[4]); 
rlllO:  x[4]/(x[4]  +  x[5]); 
rlll6:  xC5]/(x[4]  +  x[S]); 

R: matrix ( 

[0, 0, 0, 0, 0, 0. 0, 0,0, 0,0,rl21,rl31, 1141, rlSl, rial, 11], 
[rl2,-l,0,0,0,  r62, 0,0, 0,0, 0.0, 0,0, 0,0,0], 

Crl3,r23, -1,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0,0] , 

[r 14, 0,r34, -1,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0] , 
Crl5,0,0,r4S, -1,0, 0,0, 0,0, 0,0, 0,0, 0,0,0], 

Erie, 0,0,0,r56, -1,0, 0,0, 0,0, 0,0, 0,0, 0,0], 
E0,r27,0,0.0,0,-l,r87, 0,0, 0,0, 0,0, 0,0,0], 
C0,0,r38,0,0,0,0,-l,r98,0,0,0,0,0,0,0,0], 

CO, 0,0,r49,0,0,0,0,-l,rl09, 0,0, 0,0, 0,0,0], 
[0,0,0,0,r510,0,0,0,0,-l,rlll0,0,0,0,0,0,0] , 
[0,0,0,0,0,r811,r711,0,0,0,-l, 0,0, 0,0,0, 0], 

CO, 0,0,0,0,0,r712,0, 0,0, 0,-1, 0,0, 0,0,0] , 

CO, 0,0,0,0,0,0,r8l3, 0,0, 0,0, -1,0, 0,0,0], 

CO, 0,0,0,0,0,0,0,r914,0, 0,0, 0,-1, 0,0,0], 

CO, 0,0,0,0,0,0,0,0,rl015, 0,0, 0,0, -1,0,0], 

C0,0,0,0,0,0,0,0,0,0,rlll6,0,0,0,0,-l,0]); 

m:schtlon(R); 

m : subst (m C 16]  *4/ 5+m Cl 5]  ,mCl5]  ,m); 
m:sub»t(-mCl6]*61592/26975+mCl4] ,mCl4] ,m); 
m: subst (mCl6]*8014/676+mCl3] ,mCl3] ,m) ; 
m: subst (mCl6]*491/2355+mCl2] ,mCl2] ,m); 
m: subst (mCi6]*9/5+m Cl 1]  ,mCll]  ,m); 
m : subst (m  Cl5] *77 177/20780+mCl4] ,mCl4] ,m) ; 
m: subst (-mCl5]*42751/2160+aCl3] ,mCl3] ,m); 
m:subst(-mCl5]*14/471+mCl2] ,mCl2] ,m); 
m: subst (mCl5] *7/4+m CIO] ,mClO] ,m) ; 
m : subst (m  Cl4] *785/108+m  Cl3] ,mCl3] ,m); 
m: subst (mCl4]*5/3+mC9] ,mC9] ,m) ; 
m : subst (m  Cl3] *6/ 157+m  Cl2] ,mCl2] ,n); 
m: subst (mCl3]*3/2+mC8] ,«C8] ,m) ; 
m:subst(mCl2]*6+mC7] ,mC7] ,m) ; 
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ra: aubst (a[ll] *9/4+0 [6]  ,a[6]  ,a) ; 
a:subst(-a[ll] *28/27+a[5] ,a[5] .a) ; 
m:subst(-a[10]*15/l4+a[4] ,a[4] ,a) ; 
a: subst(m[10]*7/3+a[5] ,a[S] ,a) ; 
a: aubat(-a[9] *6/5+a[3] ,a[3] ,a) ; 
a:aubat(a[9]*S/2+aC4] ,a[4] ,a) ; 
a: aubat C-a[8] *2/S+a[2] ,a[2] ,a) ; 
a:subst(a[8]*3+a[3] ,a[3] ,a) ; 
a:aubat(aC7]*6/S+a[2] ,a[2] ,a); 
m:subst(-a[7]*15/8+m[8] ,a[6] ,a) ; 
a :  aubat  (-a  [6]  *2S/3+a  [1]  ,a[l]  ,a) ; 
a:BubBt(a[2]+15+m[l]  ,a[l]  ,a) ; 
a: aubat (0, [0] , a) i 
m:1.0*a; 

m:aubat(l,1.0,a) ; 
m: aubat (1.5, [l.S] .a) ; 
m:*ubat(0.1,[0.1],m); 
m: aubat (0.2, [0. 2] ,a) ; 
m:aubat(0.3, [0.3] ,m) ; 
m:subst(0.4, [0.4] ,a) ; 
m: aubat (0.5, [0.6] ,m) ; 
m:subst(0.6, [0.6] ,a) ; 
m:aubat(0.7, [0.7] ,a) ; 
m:subat(0.9, [0.9] ,m); 
quit(); 


C.1.2  Entry  Trace.  A  complete  entry  trace  for  a  3  meal  cycle  is  shown  below: 

(  Philosopher  0  enters  dining  room  — ►  Philosopher  1  enters  dining  room  — ♦  Philosopher  2 
enters  dining  room  — ►  Philosopher  0  picks  up  fork  0  — ►  Philosopher  3  enters  dining  room  — ‘ 
Philosopher  1  picks  up  fork  1  — ►  Philosopher  2  picks  up  fork  2  — ►  Philosopher  3  picks  up  fork  3 
— ►  Philosopher  3  picks  up  fork  4  — ♦  Philosopher  3  puts  down  fork  4  — ♦  Philosopher  3  puts  down 
fork  3  — ►  Philosopher  2  picks  up  fork  3  — ►  Philosopher  3  leaves  dining  room  — ►  Philosopher 
4  enters  dining  room  — ►  Philosopher  4  picks  up  fork  4  — ►  Philosopher  2  puts  down  fork  3  — - 
Philosopher  2  puts  down  fork  2  — *  Philosopher  1  picks  up  fork  2  — *  Philosopher  2  leaves  dining 
room  — »  Philosopher  1  puts  down  fork  2  — ►  Philosopher  1  puts  down  fork  1  — -  Philosopher  0 
picks  up  fork  1  — ►  Philosopher  1  leaves  dining  room  — ►  Philosopher  3  enters  dining  room  — * 
Philosopher  3  picks  up  fork  3  — ►  Philosopher  0  puts  down  fork  1  — *•  Philosopher  0  puts  down  fork 
0  — ►  Philosopher  4  picks  up  fork  0  — ►  Philosopher  0  leaves  dining  room  — ►  Philosopher  2  enters 
dining  room  — ♦  Philosopher  2  picks  up  fork  2  — *  Philosopher  4  puts  down  fork  0  — ►  Philosopher 
4  puts  down  fork  4  — ►  Philosopher  3  picks  up  fork  4  — *  Philosopher  4  leaves  dining  room  — * 
Philosopher  3  puts  down  fork  4  — ►  Philosopher  3  puts  down  fork  3  — >  Philosopher  2  picks  up 
fork  3  — *  Philosopher  3  leaves  dining  room  — ►  Philosopher  2  puts  down  fork  3  — ►  Philosopher  2 
puts  down  fork  2  — »  Philosopher  2  leaves  dining  room  — *  Philosopher  1  enters  dining  room  — • 
Philosopher  1  picks  up  fork  1  — ►  Philosopher  1  picks  up  fork  2  — ♦  Philosopher  4  enters  dining 
room  — ►  Philosopher  4  picks  up  fork  4  — ►  Philosopher  4  picks  up  fork  0  — *•  Philosopher  3  enters 
dining  room  — *  Philosopher  3  picks  up  fork  3  — ►  Philosopher  1  puts  down  fork  2  — ►  Philosopher 
1  puts  down  fork  1  — ♦  Philosopher  1  leaves  dining  room  — *  Philosopher  4  puts  down  fork  0  — * 
Philosopher  4  puts  down  fork  4  — »  Philosopher  3  picks  up  fork  4  — >  Philosopher  4  leaves  dining 
room  — ►  Philosopher  3  puts  down  fork  4  — ►  Philosopher  3  puts  down  fork  3  — ►  Philosopher 
3  leaves  dining  room  — ►  Philosopher  4  enters  dining  room  — >  Philosopher  4  picks  up  fork  4 
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— *  Philosopher  4  picks  up  fork  0  — >  Philosopher  0  enters  dining  room  — >  Philosopher  2  enters 
dining  room  — *  Philosopher  2  picks  up  fork  2  — ♦  Philosopher  2  picks  up  fork  3  — *  Philosopher 
4  puts  down  fork  0  — ♦  Philosopher  0  picks  up  fork  0  — ►  Philosopher  4  puts  down  fork  4  — * 
Philosopher  0  picks  up  fork  1  — »  Philosopher  4  leaves  dining  room  — *  Philosopher  2  puts  down 
fork  3  — ►  Philosopher  2  puts  down  fork  2  — ►  Philosopher  2  leaves  dining  room  — >  Philosopher 
0  puts  down  fork  1  — ►  Philosopher  0  puts  down  fork  0  — ►  Philosopher  0  leaves  dining  room  — * 
Philosopher  1  enters  dining  room  — ►  Philosopher  1  picks  up  fork  1  — ♦  Philosopher  1  picks  up 
fork  2  — ►  Philosopher  1  puts  down  fork  2  — ►  Philosopher  1  puts  down  fork  1  — ►  Philosopher 
1  leaves  dining  room  — ♦  Philosopher  0  enters  dining  room  — ►  Philosopher  0  picks  up  fork  0  — ► 
Philosopher  0  picks  up  fork  1  — ►  Philosopher  0  puts  down  fork  1  — ►  Philosopher  0  puts  down 
fork  0  — ►  Philosopher  0  leaves  dining  room  ) 


C.l.S  SLAM  II  Code. 

GEN.K.  EDWARDS, Dining  Philosophers, 11/11/90, i, ,,,,, ,72; 
LIN, 17,6,6; 

NETWORK; 

• 

;  SLAM  II  IMPLEMENTATION  FOR  THE  DINING  PHILOSOPHERS 
» 

;  ATTRIBUTES: 

;  ATRIB(l)  =  philosopher’s  seat  number 

;  ATRIB(2)  *  number  of  meals  eaten 

;  ATRIB(3)  »  eating  service  time 

;  ATRIB(4)  =  thinking  service  time 

;  ATRIBC5)  =  time  philosopher  enters  dining  room 

;  ATRIB(6)  =  time  philosopher  begins  thinking 

;  BIRTH  OF  6  PHILOSOPHERS 

• 

t 

;  create  6  entities; 

CREATE, 0.00001,,, 5,1; 

ACT/1; 

C0LCT, ALL, Birth  Times; 

GQ0N.1; 

;  ASSIGN  ATTRIBUTES  TO  ENTITIES 

ASSIGN, ATRIB(1)«NNCNT(1)-1 , 

ATRIB(2)=0, 

ATRIB(3)*1.0; 

;  ENTER  DINING  ROOM 

ENTER  QUEUE(l); 

ACT.EXP0IC0.5); 

ASSIGN, ATRIB(S)-TN0W; 

G00N.1; 

ACT, ,ATRIB(1) .EQ.0,UPF0;  phil  0  will  pick  up  fork  0 
JICT,  ,ATRIB(1)  .EQ.  l.UPFl ;  phil  1  will  pick  up  fork  1 


C-4 


ACT, ,ATRXB(1) .EQ.2,UPF2;  phil  2  vill  pick  up  fork  2 
ACT, ,ATRIB(1) .EQ.3.UPF3;  phil  3  vill  pick  up  fork  3 
ACT, ,ATRIB(1) .EQ.4.UPF4;  phil  4  vill  piek  up  fork  4 
ACT, ,ATRIB(1) .GT.S.OR.ATRIB(l) .LT.O, ERRHND;  vrror  handler 

;  PICKING  UP  FORKS 

! 

;  fork  0 

I 

UPFO  QUEUE(2) ; 

ACT,DRAND*ATRIB(3) ; 

GOOI.l; 

ACT, ,ATRIB(1) .EQ.O.UPFl;  phil  0 
ACT, ,ATRIB(1) .EQ.4,DMF0;  phil  4 
ACT , , ATRIB (1) . IE . 0 . AID . ATRIB ( 1 ) . IE . 4 , ERRHND ; 

;  fork  1 

UPF1  QUEUE(3) ; 

ACT , DRAND* ATRIB (3) ; 

GOOK.l; 

ACT, ,ATRXB(1).EQ.1,UPF2;  phil  i 
ACT, ,ATRIB(1) .EQ.O.DNFl;  phil  0 
ACT , , ATRIB ( 1 ) . IE . 0 . ADD . ATRIB ( 1 ) . BE . 1 , ERRHND ; 

t 

;  fork  2 

UPF2  QUEUE(4) ; 

ACT,DRAND*ATRIB(3) ; 

GOOI.l; 

ACT, ,ATRIB(1) .EQ.2.UPF3;  phil  2 
ACT, ,ATRIB(1) .EQ. 1,0XF2;  phil  1 
ACT ,, ATRIB ( 1 ). IE . 1 . AID . ATRIB ( 1 ). IE . 2 , ERRHND ; 

;  fork  3 

UPF3  QUEUE(S) ; 

ACT,DRA!D*ATRIB(3) ; 

GOOI.l; 

ACT,,ATRIB(1) .EQ.3.UPF4;  phil  3 
ACT, ,ATRIB(1) .EQ.2.DXF3;  phil  2 
ACT, ,ATRIB(1) .IE.2.AID.ATRIB(1) .IE. 3, ERRHND; 

I 

;  fork  4 

UPF4  QUEUE(«) ; 

ACT,DRAID*ATRIB(3) ; 

GOOI.l; 

ACT, ,ATRIB(1) .EQ.4.UPF0;  phil  4 
ACT, , ATRIB (1) .EQ.3.DIF4;  phil  3 
ACT, ,ATR1B(1) .IE.3.AID.ATR1B(1) .IE.4.ERRHND; 
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PUTTIMG  DOHI  FORKS 


;  fork  0 

DHFO  qUEUE(7) ; 

ACT; 

<2001,1; 

ACT, ,ATRIB(1) .EQ.4,DIF4;  phil  4 

ACT. , ATRIBC 1) . IE. 0 . AID . ATRIB(l) . IE. 4 , ERRHND ; 

ACT, ,ATRIB(l).EQ.O; 

COLCT,IIT(B) , PhilO  Eat  Tint; 

;  inc  mania  aatan  for  phil  0  k  aaaign  anting  tin# 
ASSZGR , ATRIB(2)«ATRIB(2)+1 , 

ATRZB(4)*9.0; 

ACT.,, TO; 

;  fork  1 

DMF1  qUEUE(8) ; 

ACT; 

G00I.1; 

ACT, ,ATRIB(1) .Eq.O.DRFO;  philO 

ACT , , ATRIB ( 1 ) . ME . 0 . AMD . ATRIB ( 1 ) . HE . 1 , ERRHND ; 

ACT, ,ATRIB(l).Eq.l; 

COLCT,IIT(S),Phill  Eat  Tima; 

;  inc  maala  aatan  for  phil  0  k  aaaign  anting  tima 
ASSIGI , ATRIB (2) *ATRIB(2)+1 , 

ATRIB(4)*4.0; 

ACT, , ,T1; 

t 

;  fork  2 
» 

0NF2  qUEUE(9) ; 

ACT; 

G00M.1; 

ACT, ,ATRIB(1) .Eq. l.DMFl;  phil  1 

ACT , , ATRIB  C  O . ME . i . AMD . ATRIB ( 1 ) . ME . 2 , ERRHND ; 

ACT, , ATRIBC*..  Eq.2; 

C0LCT,IMT(5) ,Phil2  Eat  Tima; 

;  inc  maala  aatan  for  phil  0  k  aaaign  anting  tima 
ASSIGM , ATRIB (2) -ATRIB (2)+l, 

ATRIB(4)=7/3; 

ACT...T2; 

;  fork  3 

DNF3  QUEUE(IO) ; 

ACT; 

GOOR,1; 

ACT, ,ATRIB(1) .EQ.2.DNF2;  phil  2 
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ACT, ,ATRIB(1) .IE. 2. AID. ATRIB(l) .XE.3.ERRHHD; 
ACT, , ATRIB(l) . SQ . 3 ; 

C0LCT,XKT(5) ,Phil3  Eat  Tint; 

;  inc  nsala  satsn  for  phil  0  ft  assign  sating  tins 
ASSX6I ,  ATRIB (2) * ATRIB  (2) +1 , 

ATRIB(4)»3/2; 

ACT, , ,T3; 

» 

;  fork  4 

DNF4  QUEUE(ll) ; 

ACT; 

C00I.1; 

ACT, ,ATRIB(i) . EQ.3.DIF3;  phil  3 

ACT, ,ATRIB(1) .VB.3. AlD.ATRIB(l) ,XE.4,ERRHHD; 

ACT, ,ATRXB(1) .EQ.4; 

COLCT,IIT(S) ,Phil4  Eat  Tins; 

;  inc  nsals  satsn  for  phil  0  ft  assign  sating  tims 
ASSIGI , ATRIB(2)*ATRIB(2)+1 , 

ATRIB (4) *1; 

ACT, , ,T4; 

» 

;  LEAVE  DIRXVG  ROOM  TO  THXVK 
* 

;  philosophsr  0  thinks 

TO  ASSIGX,ATRIB(6)=TXQW; 

THKO  qUEUE(12); 

ACT , EXPO! (ATRIB (4) ) ; 

C0LCT,IIT(8), PhilO  Think  Tims; 

COLCT,IXT(S) , PhilO  Cycls  Tins; 

ACT, , .CYCLE; 

* 

;  philosophsr  1  thinks 

T1  ASSXGV , ATRIB (6 ) *TI0W ; 

THKi  qUEUE(13) ; 

ACT, EXPO! (ATRIB (4)); 

C0LCT,IIT(6) ,Phili  Think  Tins; 
C0LCT,IIT(6),Phill  Cycls  Tins; 

ACT,,, CYCLE; 

;  philosophsr  2  thinks 

T2  ASSIGI , ATRIB (8) =TI0W ; 

THK2  qUEUE(14) ; 

ACT,EXP0I(ATRIB(4)); 

COLCT , IXT(8) , Phil2  Think  Tins; 

C0LCT,IRT(5) ,Phil2  Cycls  Tins; 

ACT,,, CYCLE; 
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;  philosopher  3  th‘.nks 


T3  ASSIGN  a  ATRXB (6) bTXQV ; 

THK3  qUEUE(lS); 

ACT,EXP0X(ATRIB(4)) ; 

COLCT, IXT(6) ,Phil3  Think  Time; 

COLCT , IIT(S) , Phil3  Cycle  Time; 

ACT,,, CYCLE; 

« 

;  philosopher  4  thinks 
> 

T4  ASSIGN, ATRIB(e)*TXOW; 

THK4  qUEUE(16) ; 

ACT,EXP0V(ATRIB(4)); 

COLCT, IXT(6),Phil4  Think  Time; 

COLCT, IKT(S),Phil4  Cycle  Time; 

ACT, , .CYCLE; 

) 

;  collect  avg  cycle  time  statistics 
» 

CYCLE  COLCT, IIT(S), Avg  Cycle  Time; 

GOOK.l; 

ACT, ,ATRIB(2) .LT. 1000, ENTER;  keep  eating 
ACT,,ATRIB(2).GE.1000,DIE;  max  meals  eaten,  exit  system 

t 

;  ERROR  HANDLER 

ERRHND  qUEUE(lT) ; 

COLCT, ALL, Errors; 

ACT,,, ENTER; 

! 

;  TERHINATE 

I 

DIE  TERN, 5000; 

END; 

FIN; 


C.1.4  Ada  Code.  This  section  contains  the  following  Ada  code  for  the  Dining  Philoso¬ 
phers. 


e  procedure  Dining  Philosophers 
e  package  Philosopher  Info 
•  procedure  Dining 

-  task  Fork 

-  task  Host 
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-  task  Philosopher 

-  task  Collect  Entries 

-  task  Collect  Cycle  Stats 


C.1.5  procedure  Dining  Philosophers. 

with  Philosopher.Info,  Dining,  Text.IO; 
uss  Philosopher.Info,  Text.IO; 
procedure  Dining.Philosophers  is 

reply  :  character; 

Print .Trace  :  Boolean  :*  False; 

Hum.Meals , 

Kaximum.Entries  :  Integer  :=  0; 
package  Int.IO  is  new  Text_I0.Integer.I0  (Integer); 
begin 

Text .10. put .line  ("The  Dining  Philosophers  .  .  ."); 
Text_10.new.line (2) ; 

—  allows  user  to  input  number  of  meals 
Text.IO.put  ("Enter  number  of  meals:  "); 

Int.I0.get  (lum.Keals); 

Text_10.new.line; 

—  allow  user  to  turn  off  entry  trace  output 
Text.IO.put  ("Output  the  entry  trace  <y/n>?  "); 

Text .10. get  (reply); 

Text.IO . new.line ; 
if  reply=’y’  then 

Print .Trace  :=  True; 
end  if; 

Kaximum.Entries  :=  Vum.Phils  *  Entry.Calls  *  Hum.Meals; 
Dining  (Kaximum.Entries,  lum.Meals,  Print .Trace) ; 
end  Dining_Philosophers ; 

C.1.6  package  Philosopher  Info, 
package  Philosopher.Info  is 
Hum_Phils  :  constant  :*  5; 


C-9 


Entry.Calls  :  constant  :*  6;  —  number  of  antry  c&lls/cycla 

aubtypa  Phil.Id  is  intagar  ranga  0. .Iu»_Phils-l; 

typa  Phil.Actions  is  (antar ,  leave,  up.right.fork,  up.left.fork, 

down.right.f ork ,  down.lef t.f ork) ; 

subtypa  Evant .String  is  string  (1..3S); 

—  Thasa  antrias  correspond  to  tha  antry  quauas 

typa  Entry.Points  is  (Enter,  Pick.Up.Fork.O,  Pick.Up.Fork.l , 

Pick.Up_Fork_2,  Pick_Up_Fork_3, 
Pick_Up_Fork_4,  Put.Dosn.Fork.0 , 
Put.Down.Fork.l ,  Put_Down_Fork_2 , 
Put_Down_Fork_3,  Put_Do»n_Fork_4 , 

Think.O,  Think.l,  Tbink_2,  Think_3, 
Think_4) ; 

type  Qing.Stat.Record  is  record 
service  :  duration  :*  0.0; 

wait  :  duration  :=  0.0; 

delta_arrival  :  duration  :=  0.0; 

last.arrival  :  duration  :*  0.0; 

and  record; 

—  This  is  a  global  array 

Qing.Stats  :  array  (Entry.Points)  of  Qing.Stat.Racord; 

function  Gat.Entry.Zndax 

(Id  :  Philosophar.Inf o . Phil.Id ; 

Action  :  Philosophar.Inf o. Phil.Actions) 

return  Entry.Points; 


function  Craata.Traca.String 

(Id  :  Philosophar.Inf o. Phil.Id; 

Action  :  Philosophar.Inf o. Phil.Actions) 

return  Evant.String; 


end  Philosophar.Inf o; 

package  body  Philosophar.Inf o  is 

function  Get.Entry.Indax 

(Id  :  Philosophar.Inf o. Phil.Id; 

Action  :  Philosophcr.Info. Phil.Actions) 

i'?tura  Entry.Points  is 

Index  :  Entry.Points; 
begin 

case  Action  is 

when  antar  =>  Index  :s  Enter; 
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when  up.right.fork  «> 
ease  Id  ia 

whan  0  »>  Indax  :* 
whan  1  »  Indax  :* 
whan  2  »>  Indax  :* 
whan  3  «>  Indax  :* 
whan  4  *>  Indax  :* 
and  caaa; 

whan  up_left_fork  =■> 
caaa  Id  ia 

whan  0  =>  Indax  :* 
whan  1  *>  Indax  :■ 
whan  2  »>  Indax  :* 
whan  3  »>  Indax  :» 
whan  4  *>  Indax  := 
and  caaa; 

whan  down.right.fork  -> 
caaa  Id  ia 

whan  0  =>  Indax  : = 
whan  1  =>  Indax  := 
whan  2  =>  Indax  :» 
whan  3  =>  Indax  := 
whan  4  =>  Indax  :* 
and  caaa; 

whan  down_laft_iork  => 
caaa  Id  ia 

whan  0  =>  Indax 
whan  1  *>  Indax  :s 
when  2  =>  Indax  := 
when  3  =>  Indax  := 
whan  4  =>  Indax  := 
end  casa; 

when  leave  -> 
caaa  Id  is 

when  0  =>  Index 
when  1  =>  Index  := 
when  2  =>  Index 
when  3  *>  Index  := 
when  4  =>  Indax  := 
and  casa; 
end  case; 
return  Indax; 
end  Get_Entry_Index ; 


Pick_Up_Fork_l 

Pick_Up_Fork_2 

Pick_Up_Fork_3 

Piek_Up_Fork_4 

Pick_Up_Fork_0 


Pick_Up_Fork_0 

Pick_Up_Fork_l 

Pick_Up_Fork_2 

Pick_Up_Fork_3 

Pick_Up_Fork_4 


Put_Down_Fork_ 1 
Put_Down_Fork_2 
Put_Down_Fork_3 
Pnt_Down_Fork_4 
Put_Down_Fork_0 


Put_Down_Fork_0 ; 
Put_Down_Fork_l ; 
Put_Down_Fork_2 ; 
Put_Down_Fork_3 ; 
Put_Down_Foik_4 ; 


Think.O 

Think.l 

Think_2 

Think.3 

Think_4 


function  Create_Trace_String 

(Id  :  Philosopher_Info.Phil.Id; 

Action  :  Philosopher.Infe. Phil. Act ions) 

return  Evant.String  is 

Event  :  Evant.String  :=  (others  =>  ’  ’); 
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begin 

Event  (1..11)  :»  "Philosopher"; 
ease  Action  is 
when  enter  »> 

Event  (12.. 13)  :■  Phil.Id ’image (Id); 

Event  (14.. 32)  :»  "  enters  dining  room"; 
when  leave  »> 

Event  (12.. 13)  :»  Phil.Id’ image (Id) ; 

Event  (14. .32)  :*  "  leaves  dining  room"; 
when  up.right.fork  *> 

Event  (12.. 13)  :*  Phil.Id’ image (Id); 

Event  (14.. 27)  :■  "  picks  up  fork"; 
if  Id/=4  then 

Event  (28.. 29)  :«  Phil.Id ’  image (Id+1); 

else 

Event  (28.. 29)  :  =  Integer* image (0) ; 
end  if; 

when  up_left_fork  => 

Event  (12.. 13)  :»  Phil.Id’ image ( Id) ; 

Event  (14.. 27)  :*  "  picks  up  fork"; 

Event  (28.. 29)  :  =  Phil.Id' image (Id) ; 
when  down_right_fork  => 

Event  (12.. 13)  :=  Phil.Id’ image ( Id) ; 

Event  (14.. 28)  :=  "  puts  down  fork"; 
if  Id/=4  then 

Event  (29.. 30)  :=  Phil.Id’ image (Id+1); 
else 

Event  (29.. 30)  :=  Integer* image(O) ; 
end  if; 

when  down.left.fork  => 

Event  (12.. 13)  :=  Phil.Id’ image ( Id) ; 

Event  (14.. 28)  :=  "  puts  down  fork"; 

Event  (29.. 30)  :  =  Phil.Id* image ( Id) ; 
end  case; 
return  Event; 
end  Create.Trace.String; 

end  Philosopher.Info; 

C.1.7  procedure  Dining. 

with  Philosopher.Info,  Calendar; 
procedure  Dining  (Ium_Entries  :  in  Integer; 

Mum_Neals  :  in  Integer; 

Print.Trace  :  in  Boolean)  is 

Trace  :  array  (1. .Vum.Entries)  of  Philosopher.Info. Event.String; 
task  type  Philosopher  is 

entry  Birth  (I  :  in  Philosopher.Info. Phil.Id; 

t.think  :  in  Float); 
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•ad  Philosopher; 
task  type  Fork  is 

•ntry  Pick_Up  (t.accapt  :  out  Duration); 

•ntry  Put_Down(t_accept  :  out  Duration); 

•nd  Fork; 

task  Host  is 

•ntry  Enter  (t.accapt  :  out  Duration); 

•ntry  L*av«  (t.accapt  :  out  Duration); 

•nd  Host; 

task  Coll*ct_Entri*s  is 

•ntry  Rext.Entry  (Id  :  in  Philosopher.Inf o . Phil.Id ; 

Action  :  in  Philosopher.Inf o. Phil. Actions) ; 
•ntry  Output .Trace; 

•nd  Collect.Entries ; 

task  Collect.Cyde.Stats  is 

•ntry  Start_of_Day  (Id  ;  Philosopher.Inf o . Phil.Id ; 

Tine  ;  Duration) ; 

•ntry  Pass.Timing  (Id  :  Philoaopher_Inf o . Phil.Id ; 

t .think, 
t.eat , 

t.wait  :  duration) ; 

•ntry  End.of.Day  (Id  :  Philosophar_Info.Phil.Id; 

Tima  :  Duration); 

•nd  Coll«ct_Cycl«.Stats; 

Forks  :  array  (Philosopher.Inf o . Phil.Id)  of  Fork; 

Philosophers  :  array  (Philosopher.Inf o . Phil.Id)  of  Philosopher; 


task  body  Philosopher  is  separate; 

task  body  Fork  is  separata; 

task  body  Host  is  separate; 

task  body  Coll«ct„Entri«s  is  separata; 

task  body  Coll«ct_Cycl«.Stats  is  separate; 

begin 

Philosophers (0) . Birth (0 , 9.0); 
Philosophers(l).Birth(l,4.0); 

Philosophers (2) .Birth(2,2.333) ; 
Philosopher  s (3) . Birth (3 ,1.5); 

Philosophers (4) .Birth(4, 1.0) ; 

end  Dining; 

C.1.8  task  Fork. 

separate(Dining) 
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task  body  Fork  is 


—  A  fork  can  be  picksd  up  or  put  down.  Ths  Fork  task 

—  accspts  calls  to  PickJJp  and  PutJDown  ssqusntially. 

—  t.accept  is  rstumsd  to  ths  calling  task  and  is  ussd 

—  to  determine  ths  service  and  wait  tints  lor  ths 

—  sntry  qususs. 


begin 

loop 

sslset 

accspt  PickJJp  (t.accspt  :  out  Duration)  do 
t.accspt  :»  Calendar. Seconds (Calendar. Clock); 
end  PickJJp; 

accept  Put _Dovn(t.accept  :  out  Duration)  do 
t.accept  :■  Calendar. Seconds (Calendar. Clock); 
end  Put .Dorn; 
or 

terninate ; 
end  select; 
end  loop; 
end.  Fork; 

C.1.9  task  Host. 

separate (Dining) 
task  body  Host  is 


—  The  host  stands  at  the  door  ol  the  dining  room  and 

—  allows  the  philosophers  to  enter  or  leave. 

—  Only  lour  philosophers  are  allowed  in  the  dining 

—  room  at  a  time  in  order  to  prevent  deadlock. 

—  t.accept  is  returned  to  the  calling  task  and  is  used 

—  to  determine  the  service  and  wait  times  lor  the 

—  entry  queues. 


Num.in.Room  :  integer  :=  0; 

Id  :  Philoeopher_Inlo.Phil.Id; 

begin 

loop 

select 

when  lum_in_Room  <  4  => 

accept  Enter  (t.accept  :  out  Duration)  do 

t.accept  :  =  Calendar. Seconds (Calendar .Clock) ; 
end  Enter; 

Xum.in.Room  :=  Xum.in.Room  +  1; 
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when  lum.in.Room  >  0  => 

accept  Leave  (t.accept  :  out  Duration)  do 

t.accept  :»  Calandar.Saconda (Calendar. Clock); 
and  Laava; 

lum.in.Room  :■  lum.in.Room  -  1; 
or 

terminate; 
and  select; 
and  loop; 
and  Host; 

C.1.10  task  Philosopher. 

with  Text.IO,  Calendar,  Random_Mumber; 
use  Text.IO,  Random.Iumber; 
separate (Dining) 
task  body  Philosopher  is 

—  Package  Random.Iumber  contains  the  function  Hart 

—  that  returns  a  random  float.  The  random  number 

—  generator  is  used  for  the  eating  and  thinking  delays. 

package  flt.io  is  new  text_io.float_io(float); 


Eating_Time  :  float  :  =  0.8; 
Thinking.Time  :  float; 

Double  :  float  ;*  2.0; 


Left.Fork, 
Right .Fork, 
Temp, 

Id 

Meals.Eaten 
Entry.Index , 
Entry.Index.R 


Philosopher.Inf o . Phil.Id ; 
Integer  0; 

Philosopher.Inf o .Entry.Points ; 


Beg.Think, 

Beg.Eat , 

Beg.of .Cycle, 

End.of. Cycle  :  Duration  :=  0.0; 


q_ arrival, 

q.arrival.R, 

q.accept, 

q.accept.R, 

q.complata, 

q.eomplete.R  :  duration  0.0; 


use  Philosopher .Info; 

package  Dur.IO  is  new  Fixed.IO  (Duration);  use  Dur.IO; 
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begin 

—  get  seat  assignment  and  thinking  tin* 
accept  Birth  (I  :  in  Philosopher_Info.Phil.Id; 

t.think  :  in  Float)  do 

Id  :«  I; 

Thinking_Tine  :»  t.think; 
end  Birth; 

Collect_Cycle_Stats.Start.of .Day  (Id,  Calendar. Seconds (Calendar. Clock) ) ; 

~  get  fork  assignaents 
Left.Fork  :*  Id; 

Teap  :«  (integer (Left.Fork)  +  1)  aod  S; 

Right .Fork  :•  Philosopher.Info.Phil.Id(Teap) ; 

while  Heals.Eaten  <  BuaJCeals  loop 

Beg.of. Cycle  ;*  Calendar. Seconds (Calendar. Clock) ; 

-  enter  dining  rooa/collect  qing  stats/add  entry  to  trace 

q.arrival  :*  Calendar. Seconds (Calendar. Clock); 

Host . Enter (q.accept) ; 

q.complete  :*  Calendar. Seconds (Calendar. Clock) ; 

Entry.Index  :•  Get_Entry_Index( Id .enter); 
qing_Stats(Entry_Index) . service  :  * 

Qing.Stats (Entry.Index) .service  +  (q.complete  -  q.accept); 
Qing_Stats (Entry.Index) .wait  := 

Qing_Stats (Entry.Index) .wait  +  (q.accept  -  q.arrival); 
if  Qing.Stats (Entry.Index). last.arrival  /=  0.0  then 
Qing_Stats(Entry_Index) .delta.arrival  := 

q.arrival  -  Qing.Stats (Entry.Index) .last.arrival; 

end  if; 

Qing_Stats (Entry.Index) .last.arrival  :=  q.arrival; 

Collect .Entries. Next .Entry  (Id,  enter); 

-  pick  up  left  fork  and  collect  qing  stats  and  entry  trace 

q_arrival  :=  Calendar. Seconds (Calendar. Clock); 

Forks (Left_Fork) .Pick_Up(q_accept) ; 

Entry.Index  :*  Get_Entry_Index(Id,up_left_fork); 
if  Qing_Stats (Entry.Index). last. arrival  /s  0.0  then 
Qing_Stats(Entry_Index) .delta. arrival  := 

q_arrival  -  Qing.Stats (Entry.Index) .last.arrival; 

end  if; 

Qing.Stats (Entry.Index) .last.arrival  :»  q.arrival; 

Collect .Entries. Next .Entry  (Id,  up.lef t.f ork) ; 

-  pick  up  right  fork 

q_arrival_R  :=  Calendar. Seconds (Calendar. Clock) ; 

Forks (Right.Fork) .Pick_Up(q_accept_R) ; 
q_complete_R  Calendar. Seconds (Calendar. Clock) ; 
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Eatry_Indtx.il  :■  Get_Entry_Indtx(Id,up_right_fork); 
if  qing_Stata(Entry_Xndax_R) .latt.arrival  /*  0.0  xhtn 
qing_Stats(Entry_Indax_R) .dalta_arrival  :« 

q_arrival.il  -  qing_Stats (Entry.Indax.R) . latt.arriv&l ; 

tad  if; 

Qing.Statt (Entry.Indax.R) . lnit._  arrival  :■  q.arrival.R; 
Collact.Entritt.Itxt .Entry  (Id.  up.right.f ork) ; 

—  tat 

Btg  .Eat  :»  Cal tndar.Stcondt(Caltndar .Clock) ; 
dtlay  duration ( Eat ing.Tiat  *  Itxt); 
q.complttt  :■  Caltadar. Stcondt(Caltndar. Clock) ; 

Qing.St at a (Entry.lndtx) . ttrvict  : « 

Qing_Statt(Eatry.Indtx).ttrvict  +  (q.complttt  -  q.accept); 
Qing.Stata (Entry.lndtx) . vait  :  = 

qing_Stat« (Entry.lndtx). wait  +  (q_acctpt  -  q.arrival); 

dtlay  duration(Eating_Tima  *  Itxt); 
q_conplttt_R  :«  Caltndar.Stcondt(Caltndar. Clock); 
qing.Stata (Entry.Indax.R) .ttrvict  : > 

qing_Statt(Entry_Xndax_R) .ttrvict  +  (q.conpltta.R  -  q.accapt.R) ; 
qing.Statt (Entry.Indax.R) .vait  :  * 

qing_Stata(Entry_Indax_R).vait  +  (q.acctpt.R  -  q.arrival.R); 

—  put  dovn  right  fork 

q.arrival  :■  Calendar . Stconda (Calendar . Clock) ; 

Forks (Right .Fork) .Put.Dovn(q.acctpt) ; 
q.complttt  :■  Caltndar. Stconda (Calendar . Clock) ; 

Entry.lndtx  :*  Gtt_EntTy_Indtx(Id,down.right_fork) ; 

Qing.Statt (Entry.lndtx) .  ttrvict  : « 

qing.Stata (Entry.lndtx). ttrvict  +  (q.complttt  -  q.accapt); 
qing_Stats (Entry.lndtx) .wait  :* 

qing.Stata (Entry.lndtx). wait  +  (q.acctpt  -  q.arrival); 
if  qing.Statt (Entry.lndtx) .latt.arrival  /=  0.0  thtn 
qing.Stats(Entry.Indtx) .dtlta. arrival  := 

q_arrival  -  qing.Statt (Entry.lndtx) .latt.arrival; 

and  if; 

qing_Statt (Entry.lndtx). latt.arrival  :»  q.arrival; 
Collact.Entritt.Itxt .Entry  (Id,  down.right.f ork) ; 

—  put  down  laft  fork 

q.arrival  :=  Caltndar. Stcondt (Caltndar. Clock); 

Forks (Ltf t.Fork) .Put_Down(q_accapt) ; 
q.complttt  :«  Caltndar. Sacondt(Caltndar. Clock); 

Entry.lndtx  :=  Gat_Entry_Index(Id,down_ltft_fork); 
qing_Stats (Entry.lndtx) . ttrvict  : 3 

qing_Statt (Entry.lndtx). ttrvict  *  (q_complata  -  q.accept); 
qing_Stats (Entry.lndtx) .wait  := 

qing.Stata (Entry.lndtx). wait  +  (q.acctpt  -  q.arrival); 
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if  Q ing.St at s (Entry.Index) .last.arrival  /*  0.0  than 
Q ing.St at ■ (Entry.Index ) . delta. arrival  : « 

q.arrival  -  Qing.Stats (Entry.Index) .last. arrival; 

and  if; 

Qing.Stats (Entry. Index) .last .arrival  :■  q.arrival; 
Collect_Eatries.Iext_Bntry  (Id,  down_lef t.f ork) ; 

Maala.Eataa  :«  Meals.Eaten  +  1; 
leave  dining  roo» 

q.arrival  :■  Calendar. Seconds (Calendar. Clock); 

Hoet .Leave (q.accept) ; 

Entry.Index  :«  Oet.Entry_Index(Id, leave); 
if  Qing_State (Entry .Index). last .arrival  />  0.0  then 
Qing.Stats (Entry.Index) . delta.arr ival  :  = 

q.arrival  -  qing.Stata(Entry.Index) .last.arrival; 

end  if; 

Qing.Stats (Entry.Index). last.arrival  :*  q.arrival; 

Collect .Entries. Next.Entry  (Id,  leave); 

Beg.Think  :«  Calendar. Seconds (Calendar. Clock); 
delay  duration(Double  *  Thinking_Time  *  Next); 
q.complete  :■  Calendar. Seconds (Calendar. Clock) ; 

Qing.Stats (Entry.Index) . service  : * 

Qing.Stats (Entry. Index). service  +  (q.complete  -  q.accept); 
Qing.Stats (Entry.Index) . wait  :  * 

Qing.Stats (Entry.Index). wait  +  (q.accept  -  q.arrival); 

End.of. Cycle  :«  Calendar. Seconds (Calendar. Clock); 

Collect.Cyde.Stats .  Pass.Timing 
(Id, 

End.of .Cycle  -  Beg.Think, 

Beg.Think  -  B«g_Eat, 

Beg_Eat  -  Beg.of .Cycle) ; 


end  loop; 

Collect.Cyde.Stats . End.of .Day  (Id,  Calendar. Seconds (Calendar. Clock) ) ; 

end  Philosopher; 

C.l.U  task  Collect  Entries. 

with  Text.IO;  use  Text.IO; 

separate(Dining) 

task  body  Collect.Entries  is 
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Tha.Id  :  Philosophar.ini o . Phil_Id ; 

Tha.Action  :  Philoaophar.Info. Phil. Actions; 

begin 

for  i  in  1. ,Iun_Entri*s  loop 
accopt  laxt.Bntry 

(Id  :  in  Philoaophar_Inio.Phil.Id; 

Action  :  in  Philoaophar.Info. Phil. Actions)  do 
Tha.Id  :»  Id; 

Tha.Action  :■  Action; 
and  Vaxt.Entry; 

Traca( i)  : «  Philoaophar.Info . Craata.Traca.String 

(Tha.Id,  Tha.Action); 

and  loop; 

accapt  Output .Traca; 
if  Print.Traca  than 

for  i  in  1. .Mua.Entriaa  loop 
Taxt_IO.put.lina  (Traca(i)); 
and  loop; 
and  if; 

and  Collact.Entriaa ; 

C.1.12  task  Collect  Cycle  Stats. 

with  Taxt.IO;  usa  Taxt.IO; 
separata (Dining) 

task  body  Collact.Cyda.Stats  is 
us*  Philoaophar.Info; 

packag*  Int.IO  is  na*  Intag*r_IO( Integer); 
package  Flt.IO  is  new  Float.IO (Float); 
packag*  Clock_IO  is  new  Fixad.IO(Duration) ; 
packag*  Entry.IO  is  nan  Enumeration. 10 (Entry .Points); 
use  Int.IO,  Flt.IO,  Clock.IO,  Entry.IO; 

Total.Loops  :  Integer  :=  (Kua_Maals  +  2)*Ium_Phils; 

—  record  start  and  stop  times  in  an  array 
type  Timas  is  array  (Phil.Id)  of  Duration; 

Start.Timas , 

End.Timas  :  Timas; 

—  record  timing  information  for  each  cycle 
type  Timing.Racord  is  record 
think  :  duration; 
wait  :  duration; 
eat  :  duration; 
and  record; 

type  Timing.Array  is  array  (Phil.Id,!. .Ium_Meals)  of  Timing.Racord 
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Cyda.Timaa  :  Timing_Array; 
Total  :  Timing. Re cord; 


—  keep  track  of  unbar  of  tiaaa  philoaophara  aat 
typo  Maala  ia  array  (Phil_Xd)  of  Integer; 

Meda.Batan  :  Maala  :«  (othara  ■>  0); 

Pid  :  Phil. Id; 

Cyda.Totd, 

Cycla.Subtotal, 

Think, 

Wait, 

Eat  :  Duration; 

lambda, 

mu, 

rho, 

W,  T,  X,  I  :  float  :«  0.0; 
begin 

put.lineO'total  loopa  ■  "  ft  integer 'image(total.loopa)) ; 

—  collact  raw  data 

for  i  in  1. .Total.Loopa  loop 
put.lina  ("loop  numbar  "  k  integer’ image(i)) ; 
aalaet 

accapt  Start.of.Day  (Id  :  Philoaophar_Info.Phil_.Id 

Tima  :  Duration)  do 

Start.Timea(Id)  ;■  Tima; 
and  Start .of .Day; 
or 

accapt  Paaa.Timing  (Id  :  Philoaopher_Info.Phil.Id 

t .think, 
t.aat, 

t.wait  :  duration)  do 


Pid 

:*  Id; 

Think 

:*  t. think; 

Eat 

:*  t.aat; 

Vait 

:»  t.wait; 

and  Paaa.Timing; 

Maala.Eatan(Pid)  :*  Maala.Eatan(Pid)  +  1; 
Cyda_Timaa(Pid,Maala.Eatan(Pid))  : * 

(Think,  Vait,  Eat); 
or 

accapt  End_of_Day  (Id  :  Philoaopher_Info.Phil.Id 

Time  :  Duration)  do 

End.Timea(ld)  s*  Tima; 
and  End_of.Day; 

and  aalaet; 
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•ad  loop; 


—  generate  cycle  statistics 
tor  1  in  Phil.Id  loop 
Think  :■  0.0; 

Wait  :■  0.0; 

Bat  :<■  0.0; 

put_lin«  ("Philosopher"  k  Phil.Id*  inage(i)  k  "  Average  Cycle  Times"); 
tor  j  in  1 .  .Iun.M#als  loop 

—  sum  the  cycle  tines 

Think  :»  Think  +  Cyde.Tines(i,j). think; 

Wait  Wait  ♦  Cyele_Tines(i,j).»ait; 

Bat  :»  Eat  +  Cycle_Tines(i,j).eat; 

end  loop;  —  j  index 

Total. think  :»  Total. think  ♦  Think; 

Total. wait  ;■  Total. wait  +  Wait; 

Total. eat  :»  Total. eat  +  Bat; 

Cycle.Subtotal  ;■  Think  +  Wait  +  Eat; 

Cycle.Total  :■  Cycle.Total  +  Cycle.Subtotal; 

—  output  average  cycle  statistics 
put  ("Thinking  Tine  «  "); 
put  (duration(Think/Vun.Keals) ,  fore*>6); 
new. line; 

put  ("Waiting  Tine  «  "); 

put  (duration(Wait  /lun.Meals) ,  f ore=>6) ; 

nev.line; 

put  ("Eating  Tine  »  "); 

put  (duration(Eat  /lun_Meals),  fore*>6); 

nev.line; 

put  ("Delta  Cycle  Tine  =  "); 
put(End_Times(i)  -  Start.Tines(i) ,  lore*>8); 
nev.line; 

put  ("Actual  Tine  *  "); 

put  (Cycle.Subtotal,  fore=>6); 
nev.line; 

put  ("Overhead  *  "); 

put  (End.Tines(i)  -  Start.Tines(i)  -  Cycle.Subtotal,  fore=>6) ; 
ne*_line(2) ; 
end  loop;  —  index  i 

put.line  ("Averages  lor  all  the  Cycles"); 
put  ("Thinking  Tine  *  ") ; 

put  (duration (Total. think/ (Iun.Phils  *  Vun.Meals) ) ) ; 
nev.line; 
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put  ("Waiting  Tiaa  ■  "); 

put  (duration(Total.vait/(Xua_Phils  *  Xum.Meala))) ; 
nev.line; 

put  ("Eating  Tiaa  ■  "); 

put  (duration(Total . eat/(Iua_Phils  *  Xuajleals))); 
nev.line; 

—  output  qing  atata 
nev.line(2) ; 

put.lina  ("  Queueing  Tiaing  Statiatica  ");  nev.line; 

put.lina  ("  Dalta"); 

put.lina  ("Entry  Point  Arrival  Tiaa  Sarvica  Tima  Wait  Time"); 

put.lina  (" - —  - — .  - - — - —  - ")• 

for  i  in  Entry.Pointa  loop 
put  (i,  width*>18) ; 

put  (duration(Qing.Stata(i) .delta_arrival/(Kum_Meals-l)) ,  f ore=>5) ; 
put  (duration(Qing.Stats(i).service/XumJfeals),  fore=>10); 
put  (duration(Qing.Stata(i) .vait/Ium.Neala) ,  fore»>10) ; 
nev.line; 
end  loop; 

X  »■  float(Xum.Neala); 

for  i  in  Entry.Pointa  loop 

X  :*  float(Qing_Stats(i) .delta., arrival) ; 
lambda  :*  (X-i.0)/X; 

X  :*  float (qing_Stats(i). service); 
mu  ;«  X/X; 

rho  :=  lambda  /  mu; 

W  :*  (rho/mu)/(1.0-rho); 

T  :=  (1.0/au)/(1.0-rho); 


nev.line; 

entry.ZO.put  (i,  vidth*>18);  nev.line; 


put  (" 

lambda 

* 

flt.IO.putd  mbda, 

exp=>0,aft=>4) ; 

nev.line; 

put  (» 

mu 

X 

"); 

flt.IO.putd'w , 

exp=>0,aft=>4) ; 

nev.line; 

put  (" 

rho 

S 

"); 

flt.IO.put(rho, 

exp*>0,aft=>4) ; 

nev.line; 

put  (" 

W 

X 

flt_IO.put(W, 

exp*>0,aft=>4) ; 

nev.line; 

put  (" 

T 

x 

flt.IO.putd, 

exp=>0,aft=>4) ; 

nev.line; 

end  loop; 

Collect .Entries . Output .Trace ; 
end  Collect.Cycle.Stata ; 
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